Author Topic: Open source lxi-tools v2.7 released  (Read 19687 times)

0 Members and 1 Guest are viewing this topic.

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Open source lxi-tools v2.7 released
« on: January 31, 2022, 09:41:33 pm »
Hello everyone!

I'm happy to announce the latest release of lxi-tools - see https://lxi-tools.github.io for more details.

lxi-tools is a collection of open source software tools for managing network attached LXI compatible test instruments such as modern oscilloscopes, power supplies, spectrum analyzers etc.

The lxi-tools open source project provides the following key components:
  • "lxi" - a command line tool that features a simple interface for discovering LXI compatible instruments, sending SCPI messages, capturing screenshots, benchmarking, and scripted automation
  • "lxi-gui" - a GUI application that features some of the same features as the command line tool and additional features such as a screenshot viewer and advanced scripting features
  • "liblxi" - a C library which provides a high level API for LXI instrument discovery (using VXI-11 or mDNS/DNS-SD) and basic SCPI communication (using RAW/TCP or VXI-11/TCP)

Here are some screenshots of the lxi-gui application in action:








For details on how to use the commandline interface please see https://lxi-tools.github.io


Installation

GNU/Linux
Install latest stable version using snap:  $ snap install lxi-tools
Install latest development version using snap:  $ snap install lxi-tools --edge

Visit https://snapcraft.io to see how to install snap for your GNU/Linux distribution.

Mac OS
Install latest stable version using Homebrew:  $ brew install lxi-tools

Windows
You can install e.g. Virtualbox (see https://www.virtualbox.org) and install a GNU/Linux distribution (e.g. Ubuntu 21.10) in a VM in which you can install and run lxi-tools.

Note: Remember to reconfigure your VMs network interface to use a bridged network adapter (not NAT) else the default instrument search feature will not work.
Note: Soon Windows users will be able to easily install and run lxi-tools via WSL2/WSLg.



Motivation
This open source project is for people who don't care for the proprietary, costly, and often times inferior tools available for managing LXI compatible instruments. The very reason I authored lxi-tools/liblxi is because I want simpler and better tools for managing my test instruments. Stuff like NI VISA drivers/tools etc. are just too bloated for my taste and not really open source friendly. I think we can do better. After all, LXI is an open standard so why not make some proper open source tools to support it! :)

Thanks to everyone in this forum who are helping to test and improve lxi-tools!  :-+


Call for contributors
Anyone who would like to contribute to this project to help make it better is welcome to join in. All contributions are welcome (bug reports, code, feature ideas, doc, testing, etc.). All source is available on Github here.

P.S: lxi-tools is not in any way affiliated with the LXI consortium. It is a fully independent open source community effort.
« Last Edit: August 19, 2023, 04:10:28 pm by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline optotester

  • Contributor
  • Posts: 44
  • Country: be
Re: Open source lxi-tools v2.0 released
« Reply #1 on: January 31, 2022, 10:53:19 pm »
Thanks Martin :) and … good news for MacOS users. Last week I have been working on porting LXI tools to MacOS and I am 99% done (some discussion in progress with one of the GTK4 lead developer as there is some bugs in GTK itself). I will most likely release it this weekend. I will do a merge request on your GitHub on Wednesday to fix some issues and replace avahi by a mdns wrapper library for full compatibility with all OSes if you are ok with that.
 
The following users thanked this post: tooki, citizenrich

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.0 released
« Reply #2 on: January 31, 2022, 11:17:04 pm »
Thanks Martin :) and … good news for MacOS users. Last week I have been working on porting LXI tools to MacOS and I am 99% done (some discussion in progress with one of the GTK4 lead developer as there is some bugs in GTK itself). I will most likely release it this weekend. I will do a merge request on your GitHub on Wednesday to fix some issues and replace avahi by a mdns wrapper library for full compatibility with all OSes if you are ok with that.

Great! That is excellent news.

For sure I am ok with that. :-+

I'm looking forward to your merge request whenever it is ready. If the mdns wrapper library works well then I expect it will be fine to replace using Avahi directly. We can make it a feature of the next release.

Meanwhile I will start the process of making lxi-tools available via https://flathub.org

https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.0 released
« Reply #3 on: February 02, 2022, 12:46:21 am »
Unfortunately I can't easily distribute a flatpak of lxi-tools in places like flathub.org

The reason is that they do not allow my application ID to reflect my true reverse DNS domain. It is mostly for policy reasons and not so much technical ones. It's all very silly.

So, if you prefer flatpak over snap, you will have to build and install the lxi-tools flatpak yourself. Instructions are available here:

https://github.com/lxi-tools/lxi-tools.flatpak

For now, snap is the way to go and maybe eventually the various distributions will include native packages of lxi-tools.
« Last Edit: February 02, 2022, 12:55:47 am by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline Sergeant82d

  • Newbie
  • Posts: 5
  • Country: us
Re: Open source lxi-tools v2.0 released
« Reply #4 on: February 02, 2022, 12:55:44 am »
Martin, and anyone else who can help me -

I was using the ver 1.21 beta on my Raspberry Pi 4 (4GB) lab computer successfully and enjoyably, connecting and controlling my four late model Siglent machines.

So I was happy yesterday when ver 2.0 was announced, and immediately tried to install it. Key word there is "tried"...

After emailing Martin, I was successful in downloading and installing the updated version, but it doesn't run. The mouse cursor spins in an hourglass for a few seconds, but that is it.

I have "refreshed" the snap several times, and also I removed and reinstalled it, while also doing a --purge on it, to no avail.

I "know" it was installed - here is what I get when checking the version from the terminal:

Quote
@raspberrypi:~ $ lxi --version
ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
lxi v2.0

Can anyone point me in the right direction to fix this?

Thanks,

Brad

(PS - first post on EEVB!)
« Last Edit: February 02, 2022, 01:02:41 am by Sergeant82d »
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.0 released
« Reply #5 on: February 02, 2022, 01:26:42 am »

Quote
@raspberrypi:~ $ lxi --version
ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
lxi v2.0

Can anyone point me in the right direction to fix this?

Actually, it looks like you are trying to start the native lxi application which must have been attempted installed at some point and maybe never worked.

To start the installed snap version of lxi-tools you should fire the following command:

Code: [Select]
$ lxi-tools.lxi-gui

Likewise, to start the command-line tool:

Code: [Select]
$ lxi-tools.lxi

Give it a try.
« Last Edit: February 02, 2022, 01:32:19 am by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6203
  • Country: ro
Re: Open source lxi-tools v2.0 released
« Reply #6 on: February 02, 2022, 08:41:06 am »
The lxi-tools v1 is dead, long live the lxi-tools v2!  ;D
« Last Edit: February 02, 2022, 08:44:58 am by RoGeorge »
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.0 released
« Reply #7 on: February 02, 2022, 10:16:08 am »
The lxi-tools v1 is dead, long live the lxi-tools v2!  ;D

Ha ha - true!
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.0 released
« Reply #8 on: February 02, 2022, 01:53:32 pm »
Quote
@raspberrypi:~ $ lxi --version
ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
lxi v2.0

Can anyone point me in the right direction to fix this?

If your problem persists try the fix described here: https://stackoverflow.com/a/50958615
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline ve7xen

  • Super Contributor
  • ***
  • Posts: 1193
  • Country: ca
    • VE7XEN Blog
Re: Open source lxi-tools v2.0 released
« Reply #9 on: February 02, 2022, 07:17:00 pm »
Installed via AUR. Looks nice and working well. Thanks!  8)
73 de VE7XEN
He/Him
 
The following users thanked this post: lundmar

Offline optotester

  • Contributor
  • Posts: 44
  • Country: be
Re: Open source lxi-tools v2.0 released
« Reply #10 on: February 03, 2022, 04:13:10 pm »
Pull request done on lxi-tools and liblxi for macOS compatibility.
liblxi can be easily compiled with meson, but I would advise to use XCode to generate a signed library.

For lxi-tools it is more complex and I did not adapt the meson build files, it has to be build through XCode (you can install the dependencies through brew, except gtk and gtksourceview5).
For gtk, you must compile manually this version: https://gitlab.gnome.org/sumibi-yakitori/gtk/-/commits/wip/chergert/yakitori/macos-fixes
For gtksourceview, you must compile the master version.

Before compiling, do not forget to run:
Code: [Select]
glib-compile-resources --target=lxi_gui-resources.c --generate-source lxi_gui.gresource.xml --c-name=lxi_gui

Before launching for the first time, do not forget to install the config file either:
Code: [Select]
cp data/io.github.lxi-tools.lxi-gui.gschema.xml /usr/local/share/glib-2.0/schemas
glib-compile-schemas /usr/local/share/glib-2.0/schemas

I will release a binary soon.
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.0 released
« Reply #11 on: February 03, 2022, 04:32:56 pm »
Pull request done on lxi-tools and liblxi for macOS compatibility.

Thanks, I'll review the PR as soon as possible.

For building on MacOs I trust you will take care of that. I don't have access to a Mac environment.

I assume MacOs has Brew channels for distributing 3rd party applications.
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline probe

  • Contributor
  • Posts: 11
  • Country: nl
Re: Open source lxi-tools v2.0 released
« Reply #12 on: February 04, 2022, 03:33:18 pm »
Hi Lundmar,

Many thanks for this fantastic tool!
May I give some feedback? LXI-tools was able to discover 5 devices (Rigol DS1054Z, Siglent SDS2104x plus, Siglent SSA 3021X Plus, Rigol DG1022Z and Rigol DP832, all "hacked" into their more capable versions (e.g. The SSA 3021X plus now thinks its is a SVA1032X) but funnily enough the only device that isn't liberated doesn't show up when running lxi discover, a Rigol DM3068. It is reachable though when I run lxi benchmark -a <IP address>. I'm happy to help out if you want me to help make it discoverable.

More pressing thing, I tried to run LXI-tools V2 on Kali, Ubuntu and Raspberry pi OS. Kali and Rpi don't have the V2 yet, Ubuntu does but when I try to run lxi-gui it gives an error that it can not connect to a screen. I installed V2 on Rpi via snap but also there you get the error that lxi-gui can not start due to a x-window error. I'm posting this from a Mac so can not post the precise error but will try in a separate post.

BTW, building from source on Kali is painful...
 

Offline probe

  • Contributor
  • Posts: 11
  • Country: nl
Re: Open source lxi-tools v2.0 released
« Reply #13 on: February 04, 2022, 03:52:47 pm »
pi@raspberrypi:~ $ lxi-gui

(lxi-gui:2313): Gdk-ERROR **: 16:44:18.660: The program 'lxi-gui' received an X Window System error.
This probably reflects a bug in the program.
The error was 'GLXBadFBConfig'.
  (Details: serial 2141 error_code 167 request_code 152 (GLX) minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.0 released
« Reply #14 on: February 04, 2022, 04:39:53 pm »
Many thanks for this fantastic tool!
May I give some feedback?
Thank you. Of course, feedback is very welcome so we can fix any bugs found!

Quote
LXI-tools was able to discover 5 devices (Rigol DS1054Z, Siglent SDS2104x plus, Siglent SSA 3021X Plus, Rigol DG1022Z and Rigol DP832, all "hacked" into their more capable versions (e.g. The SSA 3021X plus now thinks its is a SVA1032X) but funnily enough the only device that isn't liberated doesn't show up when running lxi discover, a Rigol DM3068. It is reachable though when I run lxi benchmark -a <IP address>. I'm happy to help out if you want me to help make it discoverable.

Hmm. I actually have the smaller brother DM3058 sitting right next to me and it discovers fine using the default discovery method. It does not support discovery via mDNS though. Both of these products are LXI certified and they should be discoverable with the current implementation, especially since I believe they share the same firmware codebase. Which discovery method are you using? Default or mDNS? See lxi-gui preferences.

Quote
More pressing thing, I tried to run LXI-tools V2 on Kali, Ubuntu and Raspberry pi OS. Kali and Rpi don't have the V2 yet, Ubuntu does but when I try to run lxi-gui it gives an error that it can not connect to a screen. I installed V2 on Rpi via snap but also there you get the error that lxi-gui can not start due to a x-window error. I'm posting this from a Mac so can not post the precise error but will try in a separate post.

BTW, building from source on Kali is painful...

Building lxi-tools with lxi-gui is a bit involved and painful on most distributions right now because lxi-gui requires very recent versions of core components such as GTK4.6.0, libadwaita 1.0.1, etc.

I don't expect lxi-tools to work easily or maybe at all on older distributions, with or without snap.

I think both of your issues may require quite a lot of debug so I would ask you to report your bugs in the Github issue tracker here: https://github.com/lxi-tools/lxi-tools/issues

Then we can continue from there.

Thanks.

https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.0 released
« Reply #15 on: February 04, 2022, 04:44:39 pm »
I don't know if it's the bug or how the LXI tools work, but just a remark about the DM3068 and the VXI protocol.
The DM3068 can not be accessed when using device flags at e.g. 'device_write'. I had used the flag 'WaitLock' and the communication was denied. The Rigol DG4000 with old firmware also gives an error message on the screen. Without device flags everything works without problems.

Thanks, that is very useful information. I will have to investigate - right now, I don't remember exactly which flags are in use. This is the first time I ever heard of a LXI certified instrument not being discoverable via my VXI11 discovery implementation.
« Last Edit: February 04, 2022, 05:52:55 pm by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline probe

  • Contributor
  • Posts: 11
  • Country: nl
Re: Open source lxi-tools v2.0 released
« Reply #16 on: February 04, 2022, 05:35:03 pm »
Quote
Which discovery method are you using? Default or mDNS? See lxi-gui preferences


Default, see terminal copy/paste below:

pi@raspberrypi:~ $ lxi discover -m
Searching for LXI devices - please wait...

No services found

pi@raspberrypi:~ $ lxi discover
Searching for LXI devices - please wait...

Broadcasting on interface lo
Broadcasting on interface eth0
  Found "Siglent Technologies,SDS2504X Plus,SDS2PDDxxxxxxx,5.0.1.3.9R6" on address 192.168.178.83
  Found "Siglent Technologies,SVA1032X,XXXXXXXXXX,3.2.2.5.0.r8" on address 192.168.178.80
  Found "Rigol Technologies,DG1062Z,DG1ZAxxxxxxxx,03.01.12  " on address 192.168.178.102
  Found "RIGOL TECHNOLOGIES,DP832A,DP8Cxxxxxxxxx,01.01.16" on address 192.168.178.101
  Found "RIGOL TECHNOLOGIES,DS1104Z,DS1ZAxxxxxxxxx,00.04.05.SP2" on address 192.168.178.100

Found 5 devices

pi@raspberrypi:~ $ lxi scpi -a 192.168.178.103 *IDN?
Rigol Technologies,DM3068,DM3O222400340,01.01.00.01.10.00
pi@raspberrypi:~ $
-------------------------

P.S. I can't run lxi-gui atm due to the error described above. Serials replaced by xxxx's
« Last Edit: February 04, 2022, 05:40:29 pm by probe »
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.0 released
« Reply #17 on: February 04, 2022, 05:52:02 pm »
P.S. I can't run lxi-gui atm due to the error described above. Serials replaced by xxxx's

That's fine. I assumed you were using lxi-gui but it does not matter, it's the exact same mechanism.

Give me some time, I will investigate the flag configuration that PeDre mentioned, it may be related. But first I need to fix a rather big contributed mDNS replacement feature.
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline JohanH

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: fi
Re: Open source lxi-tools v2.0 released
« Reply #18 on: February 04, 2022, 06:14:57 pm »
Unfortunately I can't easily distribute a flatpak of lxi-tools in places like flathub.org

The reason is that they do not allow my application ID to reflect my true reverse DNS domain. It is mostly for policy reasons and not so much technical ones. It's all very silly.


What craziness is that? I thought the whole idea of borrowing the reverse DNS d-bus concept was to get unique names/addresses. Can't you just use a made up name then? Now I haven't created any flatpaks (only rpms), so I'm not that familiar with their requirements.

Many distros prefer flatpak over snap nowadays, snap has become almost a Ubuntu thing only (Canonical always try to do their own race and eventually gives up and uses what everybody else does). I certainly prefer flatpaks over snaps, any day.
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.0 released
« Reply #19 on: February 04, 2022, 07:03:31 pm »
Unfortunately I can't easily distribute a flatpak of lxi-tools in places like flathub.org

The reason is that they do not allow my application ID to reflect my true reverse DNS domain. It is mostly for policy reasons and not so much technical ones. It's all very silly.


What craziness is that? I thought the whole idea of borrowing the reverse DNS d-bus concept was to get unique names/addresses. Can't you just use a made up name then? Now I haven't created any flatpaks (only rpms), so I'm not that familiar with their requirements.

Many distros prefer flatpak over snap nowadays, snap has become almost a Ubuntu thing only (Canonical always try to do their own race and eventually gives up and uses what everybody else does). I certainly prefer flatpaks over snaps, any day.

The issue is that I'm using an application ID true to my reverse DNS name, "io.github.lxi-tools.lxi-gui" but it is strongly recommended to not use hyphens in the app ID to avoid some exotic conflicting DBus use case. Flathub is enforcing this notation. Meaning it will have to look like this "io.github.lxi_tools.lxi-gui". I know this is a small detail but it really bugs me because it looks silly and everything works perfectly as it is. I can't believe that the DBus guys did not account for this situation considering they choose to base everything on the reverse DNS notation so why not make it ACCURATE!

Anyway, eventually I will probably change the app ID to agree with the recommendations but I'm not sure I really want to maintain a flatpak. There is a lot of controversy about flatpak vs snap and I have been leaning towards flatpak because I know the NIH history of Ubuntu. However, having now been through the experience of creating both a snap and a flatpak, I must say that snaps seem to be a much more well designed and mature platform and it is much easier to use. Also, there is the fundamental problem of flatpaks only being designed for distributing single binary GUI applications. I want to also distribute my command-line tool so I'm thinking I shouldn't bother with flatpaks. It is also an annoyance for end users when they go to their software store and both a flatpak and a snap turns up - it adds to the confusion.
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline JohanH

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: fi
Re: Open source lxi-tools v2.0 released
« Reply #20 on: February 04, 2022, 07:16:34 pm »

The issue is that I'm using an application ID true to my reverse DNS name, "io.github.lxi-tools.lxi-gui" but it is strongly recommended to not use hyphens in the app ID to avoid some exotic conflicting DBus use case. Flathub is enforcing this notation. Meaning it will have to look like this "io.github.lxi_tools.lxi-gui". I know this is a small detail but it really bugs me because it looks silly and everything works perfectly as it is. I can't believe that the DBus guys did not account for this situation considering they choose to base everything on the reverse DNS notation so why not make it ACCURATE!


Ah, yes, I remember now. But this doesn't really matter. AFAIK, the name is only used to identify the flatpak application, so hasn't any connection to a real DNS whatsoever.

I haven't been using snaps lately, but its true that flatpaks are aimed for GUI applications. My personal opinion is that cmd line tools are best coming from the distro repository. I see that lxi-tools are included in Fedora (very nice), but I expect it to take a while as usual before latest version is available.

I built the flatpak and sent a pull request for a small version fix for the flatpak build. (That was fast, I got the notification now it was merged).

The GUI works nicely, thanks!

Here's a screenshot of Siglent SDS1204X-E.
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.0 released
« Reply #21 on: February 04, 2022, 07:44:15 pm »
Ah, yes, I remember now. But this doesn't really matter. AFAIK, the name is only used to identify the flatpak application, so hasn't any connection to a real DNS whatsoever.

I know, it's just that I'm very particular when it comes down to details like this :)

Anyway, for now, I'll keep maintaining an unofficial flatpak for those who insists on using flatpak.

Quote
I haven't been using snaps lately, but its true that flatpaks are aimed for GUI applications. My personal opinion is that cmd line tools are best coming from the distro repository. I see that lxi-tools are included in Fedora (very nice), but I expect it to take a while as usual before latest version is available.

I agree, especially as seen from a performance perspective. The only problem is the package propagation delay. I expect that lxi-tools will eventually be picked up be the various distros but it will take months. With snaps I can literally distribute a new package via the official snap channels in minutes. Even flatpak is much slower than that because it requires human intervention to distribute via places such as flathub (needs human review etc.).

Quote
The GUI works nicely, thanks!

Here's a screenshot of Siglent SDS1204X-E.

Great. I once had the exact same model kindly sponsored by Siglent for testing with the lxi-tools project. Unfortunately it broke because someone dropped it when I was moving. R.I.P.  :'(
« Last Edit: February 04, 2022, 07:46:45 pm by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline JohanH

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: fi
Re: Open source lxi-tools v2.0 released
« Reply #22 on: February 04, 2022, 07:51:39 pm »
Just another comment about the reverse DNS name thing. This is a Freedesktop.org specification, so it isn't really flatpak that requires the strict naming thing, they just follow the specification.

Edit. But well, you could debate why they had to choose the whole naming scheme.
« Last Edit: February 04, 2022, 07:53:59 pm by jukk »
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.0 released
« Reply #23 on: February 04, 2022, 07:57:01 pm »
Just another comment about the reverse DNS name thing. This is a Freedesktop.org specification, so it isn't really flatpak that requires the strict naming thing, they just follow the specification.

Edit. But well, you could debate why they had to choose the whole naming scheme.

I know, the point is they are enforcing something which is strongly recommended but not strictly mandated.
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.0 released
« Reply #24 on: February 07, 2022, 02:45:21 am »
I have released lxi-tools v2.1

It includes a few new UI features and bug fixes.

For a full changelog see https://github.com/lxi-tools/lxi-tools/releases/tag/v2.1
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 
The following users thanked this post: JohanH

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.0 released
« Reply #25 on: February 07, 2022, 09:49:27 pm »
Hello lundmar,

I looked in your code out of interest, because I wanted to know which programming language you use. I don't know C, but I poked around in the code a bit and I noticed the structure with the flags. You use the operation flags 'WaitLock' and 'End'. I don't use flags in my programs, and so I could fix the error with DM3068. But I may be wrong, I just looked in the browser at Github.

Code: [Select]
vxi11.c

int vxi11_send(void *data, const char *message, int length, int timeout)
183 {
...
193     write_params.flags = 0x9;
...

Peter

It's okay - we figured out the problem here: https://github.com/lxi-tools/lxi-tools/issues/42

lxi-tools is working perfectly fine with the DM3068 - it was simply a user misconfiguration of the device that prevented it from responding.

It's been a long time since I've written the vxi11 client code so I had to take a quick look at the vxi11 spec and it turns out that even though I'm setting the waitlock flag, it does not have any effect because I set the lock_timeout value to 0. This means it will return with an error immediately in case the device is locked by another link, which is basically the same as not using the waitlock flag. I probably should change the flag but this code has been tested with many instruments and so far none have failed yet.
« Last Edit: February 07, 2022, 10:27:40 pm by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline Sergeant82d

  • Newbie
  • Posts: 5
  • Country: us
Still no joy on RPI4
« Reply #26 on: February 10, 2022, 01:33:52 am »
Martin,

I finally had time to work on my home lab RPI4, reworking it and getting it back up and running. New SD Card, new OS install, all updates, installed and updated Snapd, and snap installed v2.1. I did edit the "original" file that was preventing it, but...  :(

It is installed, and works from the command line, but only gives GTK errors for the lxi-gui version.

Quote

pi@raspberrypi:~ $ lxi-tools.lxi-gui

(lxi-gui:2036): Gtk-WARNING **: 19:18:25.159: Theme parser error: Default-light.css:3:20-21: Expected ':'

(lxi-gui:2036): Gtk-WARNING **: 19:18:25.169: Theme parser warning: Default-light.css:1389:19-208: Unterminated block at end of document

(lxi-gui:2036): Gtk-WARNING **: 19:18:25.169: Theme parser warning: Default-light.css:118:32-1389:208: Unterminated block at end of document

(lxi-gui:2036): Gtk-WARNING **: 19:18:25.169: Theme parser warning: Default-light.css:100:1164-1389:208: Unterminated block at end of document

(lxi-gui:2036): Gtk-WARNING **: 19:18:25.169: Theme parser warning: Default-light.css:95:111-1389:208: Unterminated block at end of document

(lxi-gui:2036): Gtk-WARNING **: 19:18:25.170: Theme parser warning: Default-light.css:95:75-1389:208: Unterminated block at end of document

(lxi-gui:2036): Gtk-WARNING **: 19:18:25.170: Theme parser warning: Default-light.css:95:39-1389:208: Unterminated block at end of document

(lxi-gui:2036): Gtk-WARNING **: 19:18:25.170: Theme parser warning: Default-light.css:93:92-1389:208: Unterminated block at end of document

(lxi-gui:2036): Gtk-WARNING **: 19:18:25.170: Theme parser warning: Default-light.css:93:11-1389:208: Unterminated block at end of document

(lxi-gui:2036): Gtk-WARNING **: 19:18:25.170: Theme parser warning: Default-light.css:91:66-1389:208: Unterminated block at end of document

(lxi-gui:2036): Gtk-WARNING **: 19:18:25.170: Theme parser warning: Default-light.css:62:786-1389:208: Unterminated block at end of document

(lxi-gui:2036): Gtk-WARNING **: 19:18:25.170: Theme parser warning: Default-light.css:62:693-1389:208: Unterminated block at end of document

(lxi-gui:2036): Gtk-WARNING **: 19:18:25.171: Theme parser warning: Default-light.css:37:99-1389:208: Unterminated block at end of document

(lxi-gui:2036): Gtk-WARNING **: 19:18:25.171: Theme parser warning: Default-light.css:16:195-1389:208: Unterminated block at end of document

(lxi-gui:2036): Gtk-WARNING **: 19:18:25.171: Theme parser warning: Default-light.css:16:162-1389:208: Unterminated block at end of document

(lxi-gui:2036): Gtk-WARNING **: 19:18:25.171: Theme parser warning: Default-light.css:16:35-1389:208: Unterminated block at end of document

(lxi-gui:2036): Gtk-WARNING **: 19:18:25.171: Theme parser warning: Default-light.css:7:898-1389:208: Unterminated block at end of document

(lxi-gui:2036): Gtk-WARNING **: 19:18:25.171: Theme parser warning: Default-light.css:7:836-1389:208: Unterminated block at end of document

(lxi-gui:2036): Gtk-WARNING **: 19:18:25.171: Theme parser warning: Default-light.css:7:402-1389:208: Unterminated block at end of document

(lxi-gui:2036): Gtk-WARNING **: 19:18:25.171: Theme parser warning: Default-light.css:4:583-1389:208: Unterminated block at end of document

(lxi-gui:2036): Gtk-WARNING **: 19:18:25.172: Theme parser warning: Default-light.css:3:15-1389:208: Unterminated block at end of document

(lxi-gui:2036): Gtk-WARNING **: 19:18:25.172: Theme parser warning: Default-light.css:3:13-1389:208: Unterminated block at end of document

(lxi-gui:2036): Gtk-WARNING **: 19:18:25.172: Theme parser error: gtk.css:1:75-76: Expected a valid selector

(lxi-gui:2036): Gdk-ERROR **: 19:18:26.686: Resource path /org/gtk/libgtk/icons/16x16/actions/value-decrease-symbolic.symbolic.png is not a valid image: Error reading png (IDAT: CRC error)
Trace/breakpoint trap



As I said - from the command line, it works fine. But... I don't want to use the command line! This is hobby stuff - I don't use it all day, or often enough to remember all the commands. Sorry.  :-//

Thanks for your help. Very much looking forward to seeing my lineup of Siglent machines on there!
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Still no joy on RPI4
« Reply #27 on: February 10, 2022, 02:14:10 am »
As I said - from the command line, it works fine. But... I don't want to use the command line! This is hobby stuff - I don't use it all day, or often enough to remember all the commands. Sorry.  :-//

That's perfectly fine - I made lxi-gui for those who prefer graphical applications. Unfortunately I suspect the problem is that the ARM build is inherently broken with GTK4 for now. The errors I see makes little sense.

Update: I've talked to some of the GTK4 developers. They say that GTK4 for arm64 is largely untested so they are not surprised there are errors.

I'll update GTK4 once they do the next official release and then maybe the problem goes away.
« Last Edit: February 10, 2022, 02:35:09 am by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Still no joy on RPI4
« Reply #28 on: February 10, 2022, 10:07:50 pm »
Quote

pi@raspberrypi:~ $ lxi-tools.lxi-gui

(lxi-gui:2036): Gtk-WARNING **: 19:18:25.159: Theme parser error: Default-light.css:3:20-21: Expected ':'

(lxi-gui:2036): Gtk-WARNING **: 19:18:25.169: Theme parser warning: Default-light.css:1389:19-208: Unterminated block at end of document

...

(lxi-gui:2036): Gtk-WARNING **: 19:18:25.172: Theme parser error: gtk.css:1:75-76: Expected a valid selector

(lxi-gui:2036): Gdk-ERROR **: 19:18:26.686: Resource path /org/gtk/libgtk/icons/16x16/actions/value-decrease-symbolic.symbolic.png is not a valid image: Error reading png (IDAT: CRC error)
Trace/breakpoint trap

Please try latest snap edge version on your RPI4:

Code: [Select]
$ snap refresh lxi-tools --edge

It uses an older version of GTK4 which prepares the resources such as Default-light.css in a different way. If it works I will work with the GTK4 devs to get it fixed in their latest version.
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline Sergeant82d

  • Newbie
  • Posts: 5
  • Country: us
RPI4 - GTK issues (fixed?)
« Reply #29 on: February 11, 2022, 12:00:28 am »
Thank you, Martin - it works!

Now that I'm in it, I do miss the "Live View" option on the screen shots tab. But otherwise, too new for me to comment on.

Thank you again.
Brad

1409392-0" alt="" class="bbc_img" />
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: RPI4 - GTK issues (fixed?)
« Reply #30 on: February 11, 2022, 01:00:12 am »
Thank you, Martin - it works!

That's great - pretty cool to see it running on a cheap single board computer like the RPI. That makes for a really cheap and handy lab setup :)

For arm64/armhf, I've upgraded the snap stable channel to use this working build so you can go back to the stable snap channel like so:
Code: [Select]
$ snap refresh lxi-tools --stable

I'll confirm the result with the GTK4 developers to see if we can fix the issue in the latest GKT4 source.

Once we have fixed it I may have to ask you to test again.

Quote
Now that I'm in it, I do miss the "Live View" option on the screen shots tab. But otherwise, too new for me to comment on.

That may return eventually but for now it is what it is :)
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline Sergeant82d

  • Newbie
  • Posts: 5
  • Country: us
RPI4 - GTK issues (fixed?)
« Reply #31 on: February 11, 2022, 01:49:57 am »
Thanks - yes, it still works with the stable version.   :-+


### EDITED TO ADD ###

I just installed the new 64-bit Raspberry Pi OS on my 4GB RPI4, and this program worked immediately on it, as well as the older 32-bit version. Just FYI.
« Last Edit: February 11, 2022, 06:20:27 pm by Sergeant82d »
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: RPI4 - GTK issues (fixed?)
« Reply #32 on: February 12, 2022, 07:13:58 pm »
Thanks - yes, it still works with the stable version.   :-+


### EDITED TO ADD ###

I just installed the new 64-bit Raspberry Pi OS on my 4GB RPI4, and this program worked immediately on it, as well as the older 32-bit version. Just FYI.

Good. I've also made a workaround for GTK4 so now the ARM64/ARMHF builds should work with the latest GTK4. These changes have been applied to the stable snap channel.
« Last Edit: February 15, 2022, 08:46:46 pm by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline Sergeant82d

  • Newbie
  • Posts: 5
  • Country: us
V2.1 Feature Request
« Reply #33 on: February 15, 2022, 11:24:11 pm »
Martin, I would like to ask for a new "Preferences" option, to set default folders to save files (screenshots, scripts, etc.) to. Thanks.
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: V2.1 Feature Request
« Reply #34 on: February 16, 2022, 12:34:58 am »
Martin, I would like to ask for a new "Preferences" option, to set default folders to save files (screenshots, scripts, etc.) to. Thanks.

You mean so that when you press "Save As.." it will always open the folder that you configured via the options?

I'm afraid that is going beyond the behaviour of the standard file chooser dialog. I don't really want to change this standard behaviour.

I understand navigating from your home folder to your save folder of choice can be tedious to repeat. However, there is a way to make that much easier: add a bookmark to your folder. Simply press "Save As.." and navigate to your folder of choice and right click the folder and click "Add to bookmarks". From then on you will have a bookmark to that folder in the left sidebar of the file dialog for easy direct navigation. Give it a try.
« Last Edit: February 16, 2022, 04:58:31 am by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 
The following users thanked this post: Sergeant82d

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6203
  • Country: ro
 
The following users thanked this post: lundmar

Offline electrodacus

  • Super Contributor
  • ***
  • Posts: 1862
  • Country: ca
    • electrodacus
Re: Open source lxi-tools v2.0 released
« Reply #36 on: March 14, 2022, 04:27:43 am »
Just found this and wanted to install as I expect a DSA815 and have a lot of tests to do.
Unfortunately I'm on the very old Linux Mint 17.1 and do not want to upgrade this year as there are to many things that I need so upgrading will be time consuming.
Then I checked what Snap Store as it is new to me and I do not like the idea seems almost like a closed source tool (guess I'm getting old :) ).
Need to find some other alternative or just do the scans manually and save the csv to USB stick for now.

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.0 released
« Reply #37 on: March 14, 2022, 02:11:47 pm »
Just found this and wanted to install as I expect a DSA815 and have a lot of tests to do.
Unfortunately I'm on the very old Linux Mint 17.1 and do not want to upgrade this year as there are to many things that I need so upgrading will be time consuming.
Then I checked what Snap Store as it is new to me and I do not like the idea seems almost like a closed source tool (guess I'm getting old :) ).
Need to find some other alternative or just do the scans manually and save the csv to USB stick for now.

Yes, DSA815 should work. It is on the list of tested instruments.

Regarding availability of lxi-tools. I'm afraid you can't have it both ways. You can't run an old distribution and have new software be available via the distributions package repositories.

The next best thing is to use snap or flatpak which are both open source and allows software maintainers to distribute their latest software in self contained environments, even on older distributions.

Alternatively, you could try find a distribution which ships the latest versions of lxi-tools and install that in a VM with bridged network adapter.

I would just go with snap if it is available on your old Mint version - it is by far the easiest way and it is actually open source (GPL). Nothing to fear there.
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline electrodacus

  • Super Contributor
  • ***
  • Posts: 1862
  • Country: ca
    • electrodacus
Re: Open source lxi-tools v2.0 released
« Reply #38 on: March 14, 2022, 05:03:05 pm »
Yes, DSA815 should work. It is on the list of tested instruments.

Regarding availability of lxi-tools. I'm afraid you can't have it both ways. You can't run an old distribution and have new software be available via the distributions package repositories.

The next best thing is to use snap or flatpak which are both open source and allows software maintainers to distribute their latest software in self contained environments, even on older distributions.

Alternatively, you could try find a distribution which ships the latest versions of lxi-tools and install that in a VM with bridged network adapter.

I would just go with snap if it is available on your old Mint version - it is by far the easiest way and it is actually open source (GPL). Nothing to fear there.

Thanks for the replay. You make a lot of good points.
I will have been willing to use a old version of lxi-tools if it was available for my distro as I do not need the graphical interface just the most basic command line.
I dislike the proprietary nature of snap (based on the super amount of research I done on the subject).
I was not aware lxi-tools was available as a flatpak (I will make a search after).
VM is also a solution but currently Windows is the only OS I run in a VM once a year to do my taxes.
Mint developers seems to agree with my view on snap and so it is not included in the recent Mint releases.
This is the article that I read yesterday when I made that original comment https://www.zdnet.com/article/linux-mint-dumps-ubuntu-snap/

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.0 released
« Reply #39 on: March 15, 2022, 08:02:00 pm »
I will have been willing to use a old version of lxi-tools if it was available for my distro as I do not need the graphical interface just the most basic command line.
I dislike the proprietary nature of snap (based on the super amount of research I done on the subject).
I was not aware lxi-tools was available as a flatpak (I will make a search after).
VM is also a solution but currently Windows is the only OS I run in a VM once a year to do my taxes.
Mint developers seems to agree with my view on snap and so it is not included in the recent Mint releases.
This is the article that I read yesterday when I made that original comment https://www.zdnet.com/article/linux-mint-dumps-ubuntu-snap/

There is an experimental flatpak here https://github.com/lxi-tools/lxi-tools.flatpak but you will have to build and maintain it yourself because I have decided not to maintain a flatpak because flatpak is only designed for distributing single binary GUI applications and not command line tools, meaning I can't distribute lxi-tools fully featured via flatpak. Also, distributing stuff via flatpak is very slow because it has to go through reviews etc.

This is in contrast to snap which supports distributing multiple binaries of any type and it allows software maintainers to literally distribute new releases within seconds. Also, having made both a flatpak and a snap for lxi-tools, I find that snap is technically much better designed and easier to use than flatpak.

Sure, Canonical made some unfortunate political decisions regarding back end store support but I think those will be sorted out in the future if they want snap to become a success. Personally I'm more focused on the technical side of things and I find snap the best technical choice.
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline electrodacus

  • Super Contributor
  • ***
  • Posts: 1862
  • Country: ca
    • electrodacus
Re: Open source lxi-tools v2.0 released
« Reply #40 on: March 15, 2022, 08:43:47 pm »
There is an experimental flatpak here https://github.com/lxi-tools/lxi-tools.flatpak but you will have to build and maintain it yourself because I have decided not to maintain a flatpak because flatpak is only designed for distributing single binary GUI applications and not command line tools, meaning I can't distribute lxi-tools fully featured via flatpak. Also, distributing stuff via flatpak is very slow because it has to go through reviews etc.

This is in contrast to snap which supports distributing multiple binaries of any type and it allows software maintainers to literally distribute new releases within seconds. Also, having made both a flatpak and a snap for lxi-tools, I find that snap is technically much better designed and easier to use than flatpak.

Sure, Canonical made some unfortunate political decisions regarding back end store support but I think those will be sorted out in the future if they want snap to become a success. Personally I'm more focused on the technical side of things and I find snap the best technical choice.

I understand your point. I'm just a particular case with particular preferences not even sure why I made the initial comment.

I looked a bit more in to the new to me standards and there is not much of a difference between flatpak and snap. Maybe Appimage was more like what I guessed flatpak is but not the case and even Appimage is not what I will have liked. I will have liked just a zip file that is decompressed and contained all dependencies and the executable file sort of like Blender was distributed last time I checked.

The problem with the current state of GNU/Linux is that if you want to use your computer for productivity like I do and have multiple software that took time to install and configure and then you need some time later another software that requires a newer version of some library updating that library my break one or more of your older software.  I have no idea what the solution to this is but I will take more time to study this next year when I will likely upgrade the computer that should also last 10 years as this last computer I have based on i7-3370 and I'm not willing to install an OS more than 2x over that period so once every 5 years.  As far as I see there is absolutely no innovation in either software of hardware to worth upgrading more often.

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26907
  • Country: nl
    • NCT Developments
Re: Open source lxi-tools v2.0 released
« Reply #41 on: March 15, 2022, 10:32:44 pm »
The problem with the current state of GNU/Linux is that if you want to use your computer for productivity like I do and have multiple software that took time to install and configure and then you need some time later another software that requires a newer version of some library updating that library my break one or more of your older software.  I have no idea what the solution to this is but I will take more time to study
The solution is quite simple: include all libraries (from libc and onwards) & other binaries your software needs to run. That is how professional software makers distribute their software as well. That way there is very little chance that the software doesn't work due to a system library missing or being the wrong version. There is no other way around it but hard drive space is cheap anyway.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline electrodacus

  • Super Contributor
  • ***
  • Posts: 1862
  • Country: ca
    • electrodacus
Re: Open source lxi-tools v2.0 released
« Reply #42 on: March 15, 2022, 11:29:43 pm »
The solution is quite simple: include all libraries (from libc and onwards) & other binaries your software needs to run. That is how professional software makers distribute their software as well. That way there is very little chance that the software doesn't work due to a system library missing or being the wrong version. There is no other way around it but hard drive space is cheap anyway.

That is how I will prefer to do things. While it works it not an elegant solution due to the size of each application.
On the other hand I see super simple basic software or even drivers that for no reason is a half gigabyte download (that is the case for this basic spectrum analyzer).
I mostly do embedded software and from this perspective things are much simpler just a .bin file containing all that is needed. As for the source code that is distributed with all needed libraries as there also things change and not only that but become incompatible.

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.0 released
« Reply #43 on: March 16, 2022, 03:09:46 pm »
The problem with the current state of GNU/Linux is that if you want to use your computer for productivity like I do and have multiple software that took time to install and configure and then you need some time later another software that requires a newer version of some library updating that library my break one or more of your older software.  I have no idea what the solution to this is but I will take more time to study this next year when I will likely upgrade the computer that should also last 10 years as this last computer I have based on i7-3370 and I'm not willing to install an OS more than 2x over that period so once every 5 years.  As far as I see there is absolutely no innovation in either software of hardware to worth upgrading more often.

Do what I do. Always keep your work station up to date with latest version of your preferred Linux distribution to benefit from latest features and security updates(!). I develop embedded micro-controller firmware and complete embedded Linux stacks for various clients and when I need something to be available for many years I simply setup my work space (toolchain, tools, source repos, etc.) in separate VMs so I can always spin them up if I need to go back and make updates. This way I can make sure that my development environments for various clients are always preserved while enjoying a fully up to date Linux work station.

To me it is absolutely inconceivable to run a 5 or 10 year old Linux system as my daily driver work station. We have very different views of what warrants an upgrade. I would argue that security and bug fix updates alone justify keeping everything up to date but more importantly there are sooooooo many components of the Linux ecosystem that are constantly evolving making your Linux experience so much better. I mean, it's 2022 and this is the time for running technologies like Gnome/Wayland, the new pipewire audio framework, systemd, vulkan, and the other zillion application/library updates etc. If you stick with an old Linux distribution you are asking for trouble and get a lesser Linux experience and you are in essence opting out of using a lot of new software. To me, that is a terrible strategy.
« Last Edit: March 16, 2022, 04:39:27 pm by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline electrodacus

  • Super Contributor
  • ***
  • Posts: 1862
  • Country: ca
    • electrodacus
Re: Open source lxi-tools v2.0 released
« Reply #44 on: March 16, 2022, 05:48:38 pm »

Do what I do. Always keep your work station up to date with latest version of your preferred Linux distribution to benefit from latest features and security updates(!). I develop embedded micro-controller firmware and complete embedded Linux stacks for various clients and when I need something to be available for many years I simply setup my work space (toolchain, tools, source repos, etc.) in separate VMs so I can always spin them up if I need to go back and make updates. This way I can make sure that my development environments for various clients are always preserved while enjoying a fully up to date Linux work station.

To me it is absolutely inconceivable to run a 5 or 10 year old Linux system as my daily driver work station. We have very different views of what warrants an upgrade. I would argue that security and bug fix updates alone justify keeping everything up to date but more importantly there are sooooooo many components of the Linux ecosystem that are constantly evolving making your Linux experience so much better. I mean, it's 2022 and this is the time for running technologies like Gnome/Wayland, the new pipewire audio framework, systemd, vulkan, and the other zillion application/library updates etc. If you stick with an old Linux distribution you are asking for trouble and get a lesser Linux experience and you are in essence opting out of using a lot of new software. To me, that is a terrible strategy.

The equivalent of your separate VM for long therm projects is my computer as I'm my own client and I only have one long therm project (multiple devices but in the same series).
Access to different computer hardware is more difficult or in some cases impossible from a VM.
I'm off grid in the middle of nowhere with a fairly low speed internet connection 2Mbps both up and down so always updating the OS is not a great option plus I consider security to be higher with the auto updates disabled.
There are no bugs in anything that I use (there may be but not affecting me). I see nothing that can make my experience better with newer software.
I do get your perspective as that is how I will work 10 to 20 years ago (always having the latest Linux distribution and testing multiple new distribution each year and also change the hardware fairly frequent).
Even my phone is on Android 4.4 and now on third battery (replaceable battery model) and have no intention to replace it unless it fails (recently I got another similar model with replaceable battery and Android 9 in case this one fails as it is my main and only internet connection).
Phone is used as a phone and access point only thus newer version will have no advantages as I do not need any other futures.
My wife has a newer Chromebook tablet with support until 2028 and the inability to control when update happens or if you even want to do that seems to me a much higher security risk (you have no control over your own device is like you do not even own it).
And software will do nothing to protect you if hardware is compromised as it is the case with all recent x86 and most ARM. Maybe my next computer will be an IBM Power 10 based assuming I can find something next year.


A good recent example in therms of security is the Airthings Wave that I purchased about a year ago and now it is a paper weight.
It measures radon gas, CO2, temperature, humidity, pressure.
In order to use it it requires you to register the device first update the firmware and then you can connect trough the app over bluetooth.
The app requires GPS to be enabled so exact location is known and it will upload data to cloud. I was going to immediately send it back but I noticed that I can use it on that (backup phone I have if I turn OFF WiFi so any outside connection).  It worked I think for about 6 months this way and then it stopped allowing me access to device and required a internet connection in order to continue to have access.
There is no way to clear the internal logged data (logged in the device not just the phone) and so as soon as I will connect this to internet it will make an update and upload all logged data to Airthings cloud. Since I'm not willing to share the data I can no longer use the device at all.
Even selling to someone else is not an option as the device was already registered that includes my details and exact GPS location and so if someone else will register (assuming it is even allowed) the 6 months of logged data will still be in the cloud.
You may think that is not an issue to share this data but I obviously disagree. Just the CO2 levels alone can reveal a huge amount about the way you live so how long you are at home how many people in the home when you are opening the windows, when you sleep (just to name a few) and in combination with all other sensors it can provide an almost unrestricted access to your life.

Sorry for the super long rambling. I was triggered by the "security updates"

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.0 released
« Reply #45 on: March 16, 2022, 10:20:50 pm »
Sorry for the super long rambling. I was triggered by the "security updates"

Ha ha, yes - that was quite a ramble triggered by you confusing "security updates" with "automatic updates".

I'm no distro shopper - that is something you do when you are learning Linux. I've been running Ubuntu Linux exclusively since 2004 and my installations have never installed system security updates automatically - that is an opt in feature.

Either way, you have to be careful with any connected product you buy in this IoT era to protect your privacy and that is exactly why it is even more important to keep up with security updates. It would be foolish to insist on running old software with known vulnerabilities that makes you the easy target of a long list of CVEs.
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline electrodacus

  • Super Contributor
  • ***
  • Posts: 1862
  • Country: ca
    • electrodacus
Re: Open source lxi-tools v2.0 released
« Reply #46 on: March 16, 2022, 11:12:28 pm »
Ha ha, yes - that was quite a ramble triggered by you confusing "security updates" with "automatic updates".

I'm no distro shopper - that is something you do when you are learning Linux. I've been running Ubuntu Linux exclusively since 2004 and my installations have never installed system security updates automatically - that is an opt in feature.

Either way, you have to be careful with any connected product you buy in this IoT era to protect your privacy and that is exactly why it is even more important to keep up with security updates. It would be foolish to insist on running old software with known vulnerabilities that makes you the easy target of a long list of CVEs.

:) I do not think I confused security updates and automatic updates.  The main reason automatic updates are a thing is supposedly for security when that may actually be the opposite.

I also started playing with Linux around the same time frame early 2000's first attempting to install RedHat (was not a fan) but then I found a way more user friendly Knoppix Live CD version that I installed and gave up using Windows at home then I got a Ubuntu Live CD (was testing many other versions) and was supper impressed with the out of the box hardware support.

The problem is bad quality software to begin with and just patching vulnerabilities when the become public will not solve much if anything.
I for example disable Hyper Threading ever since the vulnerability related to that where announced but there are so many more than can not be fixed by any software patch.
There will be no choice very soon in what you buy as everything will be internet connected and as my Airthing device can not be used without.
So while you still have control now on auto-updates in Linux it will not be long until they will be mandatory. Maybe at first just security related updates then all the others.

Offline Kibabalu

  • Regular Contributor
  • *
  • Posts: 106
  • Country: de
Re: Open source lxi-tools v2.0 released
« Reply #47 on: August 21, 2022, 04:14:22 pm »
...

I will release a binary soon.

Any news regarding the binary for macOS?
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.0 released
« Reply #48 on: September 26, 2022, 11:35:08 am »
...

I will release a binary soon.

Any news regarding the binary for macOS?

I hope that someone eventually will maintain a package for brew so it becomes easy to install on mac. Also, to get it working on mac someone needs to adapt the mDNS backend for mac (Bonjour etc.).
« Last Edit: September 26, 2022, 11:42:31 am by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.0 released
« Reply #49 on: October 14, 2022, 08:51:43 pm »
FYI - I've just released lxi-tools v2.2 which includes various updates, bug fixes, and a new popular requested feature which allows for adding instruments manually in case they are not discoverable.

Full release details are available here: https://github.com/lxi-tools/lxi-tools/releases/tag/v2.2

As usual, snap version is available immediately, distributions will take some time to update.

Happy hacking!

/Martin
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 
The following users thanked this post: coromonadalix, RoGeorge, dibro

Offline coromonadalix

  • Super Contributor
  • ***
  • Posts: 5906
  • Country: ca
Re: Open source lxi-tools v2.0 released
« Reply #50 on: October 17, 2022, 11:52:03 am »
Kinda noob here,  can it control  an    Agilent L4411A meter thru usb or lan interface, i don't have the gpib interface ....   for now

Not sure if it mimick an 34401a controls,   searching all the docs i can find about this one ... (snatched a deal on Ebay)

and finally,   do we have to install the Keysight i/o librairies even if you use an virtual box to run LXI-tool  ??


Or someone compile it for 32-64 bit windows ??
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.0 released
« Reply #51 on: October 17, 2022, 05:13:06 pm »
Kinda noob here,  can it control  an    Agilent L4411A meter thru usb or lan interface, i don't have the gpib interface ....   for now

Yes, the Agilent L4411A is a LXI class C certified device - it has that shiny LXI logo on the front  :)



This means it is discoverable via LAN and you can send SCPI commands to it via the VXI11/TCP protocol so it should work just fine with lxi-tools.

Not sure if it mimick an 34401a controls,   searching all the docs i can find about this one ... (snatched a deal on Ebay)

The complete SCPI programmers reference for this device comes in form of a MS help file but someone in this forum converted it to PDF here

and finally,   do we have to install the Keysight i/o librairies even if you use an virtual box to run LXI-tool  ??

Nope. That is the beauty of lxi-tools - it is lightweight and does not require any special drivers. If you run it in a virtual box VM you just have to make sure that the VM network adapter is a bridged network adapter, else lxi-tools will not be able to discover your device automatically on your local network.

Or someone compile it for 32-64 bit windows ??

Sorry, there is no Windows port of lxi-tools available. However, it may be possible to install and run lxi-tools, both the command-line tool lxi and the GUI tool lxi-gui, via Windows WSL2 on Windows10/Windows11 but I have no confirmation of that yet.
« Last Edit: October 17, 2022, 06:05:39 pm by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 
The following users thanked this post: coromonadalix

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.0 released
« Reply #52 on: October 19, 2022, 08:28:03 am »
@coromonadalix: Feel free to let me know if you get the Agilent L4411A working with lxi-tools. Then I can add it to our list of tested instruments. Thanks.
« Last Edit: October 19, 2022, 08:33:49 am by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline EsPiFF

  • Contributor
  • Posts: 15
  • Country: de
Re: Open source lxi-tools v2.0 released
« Reply #53 on: October 27, 2022, 06:08:13 am »
Can the liblxi be used to develop LXI devices?

I know, that lxi tools was developed as a LXI host, to connect with LXI devices. But I thought, that liblxi contains all the functionality to support both the host side as well as the device side. So, would it be possible to expose ADCs/DACs on a Raspberry Pi (maybe from a HAT) as an LXI instrument, with the liblxi?

That would be very good, to one central LXI host and device code base.
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.0 released
« Reply #54 on: October 27, 2022, 08:18:06 am »
Can the liblxi be used to develop LXI devices?

I know, that lxi tools was developed as a LXI host, to connect with LXI devices. But I thought, that liblxi contains all the functionality to support both the host side as well as the device side. So, would it be possible to expose ADCs/DACs on a Raspberry Pi (maybe from a HAT) as an LXI instrument, with the liblxi?

That would be very good, to one central LXI host and device code base.

No sorry, currently liblxi only implements client features. It is my plan at some point to add server features and that is the reason that if you look in the git repository you will find the autogenerated VXI11 server RPC source.
« Last Edit: October 28, 2022, 10:51:45 am by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline EsPiFF

  • Contributor
  • Posts: 15
  • Country: de
Re: Open source lxi-tools v2.0 released
« Reply #55 on: October 27, 2022, 10:14:04 am »
sorry for mixing up the words "device" and "host". Luckily, you still understood what I was asking, and pointed me to the correct terms "lxi client", what is the PC. And "lxi server", what is the instrument.  :)

I will follow the development here. Great that you are already working on the instrument side. My guess is, when liblxi also supports writing an instrument with it, there will be millions of installations.
 

Offline ralphrmartin

  • Frequent Contributor
  • **
  • Posts: 480
  • Country: gb
    • Me
Re: Open source lxi-tools v2.0 released
« Reply #56 on: October 27, 2022, 05:09:54 pm »
Possible problem? Or my misunderstanding?

I installed lxi-tools 2.3 via snap, on debian testing, and I am getting the following error message when running lxi-gui:
Failed to realize renderer of type 'GskGLRenderer' for surface 'GdkX11Toplevel': libEGL not available
I thought a snap was supposed to include all needed libs - or am I missing something?
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.0 released
« Reply #57 on: October 28, 2022, 10:50:03 am »
Possible problem? Or my misunderstanding?

I installed lxi-tools 2.3 via snap, on debian testing, and I am getting the following error message when running lxi-gui:
Failed to realize renderer of type 'GskGLRenderer' for surface 'GdkX11Toplevel': libEGL not available
I thought a snap was supposed to include all needed libs - or am I missing something?

Yes, it is supposed to but there is stuff that even the host environment must provide for snaps to work successfully. Is your Debian very old? Right, you are running testing. Well, testing is not considered stable so maybe it has issues. Does the snap on the stable channel (v2.2) work?

I've updated the snap edge channel to include the missing libegl so it might work now.
« Last Edit: October 28, 2022, 12:18:20 pm by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline ralphrmartin

  • Frequent Contributor
  • **
  • Posts: 480
  • Country: gb
    • Me
Re: Open source lxi-tools v2.0 released
« Reply #58 on: October 28, 2022, 03:42:11 pm »
Thanks. I did "snap refresh", and now I am getting  a slightly different message:

Failed to realize renderer of type 'GskGLRenderer' for surface 'GdkX11Popup': Failed to create EGL display


Using "snap refresh lxi-tools --stable" does not produce any such errors on launching; launching seems much slower.
« Last Edit: October 28, 2022, 03:48:10 pm by ralphrmartin »
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.0 released
« Reply #59 on: October 28, 2022, 04:22:25 pm »
Thanks. I did "snap refresh", and now I am getting  a slightly different message:

Failed to realize renderer of type 'GskGLRenderer' for surface 'GdkX11Popup': Failed to create EGL display


Using "snap refresh lxi-tools --stable" does not produce any such errors on launching; launching seems much slower.

But lxi-gui starts regardless of these errors right?

I'm getting similar errors when I start lxi-gui from the edge channel. It is errors thrown from GTK4 - they seem to vary depending on GTK4 version used so I think it is ok to ignore them.

The difference of the snaps are that on the edge channel I'm using a new snap base image (core22). It should be faster to launch.
« Last Edit: October 28, 2022, 04:27:54 pm by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline coromonadalix

  • Super Contributor
  • ***
  • Posts: 5906
  • Country: ca
Re: Open source lxi-tools v2.0 released
« Reply #60 on: October 28, 2022, 06:16:39 pm »
Woah  i lost some threads ....


@coromonadalix: Feel free to let me know if you get the Agilent L4411A working with lxi-tools. Then I can add it to our list of tested instruments. Thanks.

LXI tools like the Keysight software's ??? DMM connectivity 1.0.2.0  ok,  benchvue(s)  2017 and up are ok,  i/o librairies suite ok 

Even a basic excel sheet w macros seems to work  BUT  i think the meter as to be ready to take the measurement(s)   there is a command i don't catch ...   

Maybe thru the CONFig  command or the SENSe command  ??? before the MEASurement commands  from the sheet link  (previous thread)


Kinda  lost a little  loll   for now I'm connected thru usb  since i don't have an AR488 gpib dongle ... has to order the @artag boards


QUESTION :  could it be ported to android as an app ??? But i do think about an RASPI touchscreen version like an  cpi-a070wr (raspi panel pc)  who sit somewhere

I have an crazy idea to remotely control the meter / far away  ....   but controlled with an simple tool

I do know about some ar488 with esp wifi add on ...


I'm trying other softwares like testcontrol, but have an hard time figuring out the menus and some meter functions, even some visual studio codes etc ...   

I'm sad to see  there is no interest foe the 34410 / 34411 / l4411 series,  not sure the coding of the 34461  can or could work ??
« Last Edit: October 28, 2022, 07:59:13 pm by coromonadalix »
 

Offline ralphrmartin

  • Frequent Contributor
  • **
  • Posts: 480
  • Country: gb
    • Me
Re: Open source lxi-tools v2.0 released
« Reply #61 on: October 28, 2022, 08:33:11 pm »

But lxi-gui starts regardless of these errors right?

I'm getting similar errors when I start lxi-gui from the edge channel. It is errors thrown from GTK4 - they seem to vary depending on GTK4 version used so I think it is ok to ignore them.

The difference of the snaps are that on the edge channel I'm using a new snap base image (core22). It should be faster to launch.

Yes, lxi-gui seems to start OK. I'll ignore them for now, then, thanks, but will report back if something seems not to actually function ok.
 
The following users thanked this post: lundmar

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.0 released
« Reply #62 on: October 29, 2022, 01:47:33 am »
QUESTION :  could it be ported to android as an app ??? But i do think about an RASPI touchscreen version like an  cpi-a070wr (raspi panel pc)  who sit somewhere

Sorry, no Android app.

Yes, you can install lxi-tools on Raspian or other Linux distros such as Ubuntu and it will just work.

I have an crazy idea to remotely control the meter / far away  ....   but controlled with an simple tool

lxi-tools is a really simple tool for managing any of your network attached LXI compatible instruments. Just plug in your instrument on your LAN network and fire up lxi-tools and it should discover it.
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.0 released
« Reply #63 on: October 29, 2022, 03:30:46 pm »
I've released lxi-tools v2.3 which is a minor bug fix release that fixes an annoying bug with selecting instruments and copying IP or ID.

https://github.com/lxi-tools/lxi-tools/releases/tag/v2.3

As usual, latest version is immediately available via snap. Distributions will catch up later.
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 
The following users thanked this post: coromonadalix

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.4 released
« Reply #64 on: December 14, 2022, 08:57:16 pm »
lxi-tools v2.4 has been released: https://github.com/lxi-tools/lxi-tools/releases/tag/v2.4

Code: [Select]
Changes since lxi-tools v2.3:

    Prefix all lua functions with lxi_

    To avoid conflict with existing lua APIs.

This means lua scripts will have to be updated to call the new lua function names.
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 
The following users thanked this post: coromonadalix, RoGeorge, MegaVolt

Offline WaveyDipole

  • Frequent Contributor
  • **
  • Posts: 851
  • Country: gb
Re: Open source lxi-tools v2.4 released
« Reply #65 on: December 21, 2022, 01:45:32 pm »
Is there an appimage or Flatpack available yet? SNAP is not supported on my Linux distro. Unfortunately I am still stuck on version 1.21 CLI (which works well enough :-) ) as the package comes without the gui tool. It would be nice to be able to use the latest version with my new scope! Even the repository on Linux Mint (which is a Ubuntu derivative) only has 1.21 and does not install the GUI tool either. Due to its covert activity Mint actually disables SNAP although it can be re-enabled if required.
« Last Edit: December 21, 2022, 01:57:16 pm by WaveyDipole »
 

Offline JohanH

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: fi
Re: Open source lxi-tools v2.4 released
« Reply #66 on: December 21, 2022, 02:56:26 pm »
I've built the flatpak a couple of times. Here are the steps for someone who wants to do it:
 - Clone lundmar's flatpak repo, e.g. git clone https://github.com/lxi-tools/lxi-tools.flatpak
 - Update the commit for lxi-gui in the file io.github.lxi-tools.yaml (at the end), so in this case 5ee36cdbeb52c021930cac811b63752855e9444e for the 2.4 release
 - Pull in submodules to the git repo (git submodule init, git submodule update)
 - To build and install, run: flatpak-builder build io.github.lxi-tools.yaml --force-clean --user --install

That's it. For more details, consult flatpak documentation for your own distro.

Edit. You probably also have to do the following before building the flatpak unless they are already installed:

 - flatpak install org.gnome.Sdk
 - flatpak install org.gnome.Platform

and select version 43 for both.
« Last Edit: December 21, 2022, 07:38:43 pm by JohanH »
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6203
  • Country: ro
Re: Open source lxi-tools v2.4 released
« Reply #67 on: December 21, 2022, 03:49:19 pm »
The lxi-tools are available in the repositories (not the GUI LXI tool, the command line tool called 'lxi').  Used it a couple of days ago, installed from the Ubuntu repositories.

- To install it, from a terminal type 'sudo apt install lxi-tools'.
- To show the version, type 'lxi --version' (the one installed this week is v2.1)
- To take a screenshot, type 'lxi screenshot -a 192.168.1.4'.  Replace 192.168.1.4 with the IP address of your instruments.
- To find more, type 'man lxi'.
« Last Edit: December 21, 2022, 03:51:42 pm by RoGeorge »
 

Offline WaveyDipole

  • Frequent Contributor
  • **
  • Posts: 851
  • Country: gb
Re: Open source lxi-tools v2.4 released
« Reply #68 on: December 21, 2022, 04:14:31 pm »
The lxi-tools are available in the repositories (not the GUI LXI tool, the command line tool called 'lxi').  Used it a couple of days ago, installed from the Ubuntu repositories.

- To install it, from a terminal type 'sudo apt install lxi-tools'.
- To show the version, type 'lxi --version' (the one installed this week is v2.1)
- To take a screenshot, type 'lxi screenshot -a 192.168.1.4'.  Replace 192.168.1.4 with the IP address of your instruments.
- To find more, type 'man lxi'.

Thanks. This is what I did in the first instance - installed with apt. That installs just the CLI version. lxi-version returns

Code: [Select]
lxi v1.21
The screenshot command you kindly posted does work and I had got that far. I tested it and it works with the MSO5000 so I do have a CLI solution, even though it be an older version of the software. Which Linux distro are you using?

I've built the flatpak a couple of times. Here are the steps for someone who wants to do it:
 - Clone lundmar's flatpak repo, e.g. git clone https://github.com/lxi-tools/lxi-tools.flatpak
 - Update the commit for lxi-gui in the file io.github.lxi-tools.yaml (at the end), so in this case 5ee36cdbeb52c021930cac811b63752855e9444e for the 2.4 release
 - Pull in submodules to the git repo (git submodule init, git submodule update)
 - To build and install, run: flatpak-builder build io.github.lxi-tools.yaml --force-clean --user --install

That's it. For more details, consult flatpak documentation for your own distro.

I got as far as the pulling in submodules step which completed successfully. However the build and install step does not work.

Code: [Select]
$ flatpak-builder build io.github.lxi-tools.yaml --force-clean --user --install
error: org.gnome.Sdk/x86_64/43 not installed
Failed to init: Unable to find sdk org.gnome.Sdk version 43

I cannot tell gnome which package I need to install - there are dozens of them! Google was not too helpful either. I am still trying to figure that out. I tried gnome-devel which installed dozens of packages on my system but didn't work. If anyone has any idea which one it needs, that would be appreciated.
 

Offline JeremyC

  • Regular Contributor
  • *
  • Posts: 143
  • Country: us
Re: Open source lxi-tools v2.4 released
« Reply #69 on: December 21, 2022, 04:51:19 pm »
Quote
I got as far as the pulling in submodules step which completed successfully. However the build and install step does not work.

Code: [Select]
$ flatpak-builder build io.github.lxi-tools.yaml --force-clean --user --install
error: org.gnome.Sdk/x86_64/43 not installed
Failed to init: Unable to find sdk org.gnome.Sdk version 43

I cannot tell gnome which package I need to install - there are dozens of them! Google was not too helpful either. I am still trying to figure that out. I tried gnome-devel which installed dozens of packages on my system but didn't work. If anyone has any idea which one it needs, that would be appreciated.

Try:
Code: [Select]
sudo apt install gnome-platform-devel
However, I suggest to install "snap", or enable it if already installed and go from there.
Code: [Select]
sudo apt update
sudo apt install snapd

 

Offline JohanH

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: fi
Re: Open source lxi-tools v2.4 released
« Reply #70 on: December 21, 2022, 05:24:16 pm »

Code: [Select]
$ flatpak-builder build io.github.lxi-tools.yaml --force-clean --user --install
error: org.gnome.Sdk/x86_64/43 not installed
Failed to init: Unable to find sdk org.gnome.Sdk version 43

I cannot tell gnome which package I need to install - there are dozens of them! Google was not too helpful either. I am still trying to figure that out. I tried gnome-devel which installed dozens of packages on my system but didn't work. If anyone has any idea which one it needs, that would be appreciated.


flatpak install org.gnome.Sdk

Then select version 43.
 

Offline WaveyDipole

  • Frequent Contributor
  • **
  • Posts: 851
  • Country: gb
Re: Open source lxi-tools v2.4 released
« Reply #71 on: December 21, 2022, 05:25:48 pm »
Ok so does this install it on my system or does Flatpack keep it separate? I am told its not a good idea to mix two different installers...
 

Offline JohanH

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: fi
Re: Open source lxi-tools v2.4 released
« Reply #72 on: December 21, 2022, 05:29:12 pm »
Ok so does this install it on my system or does Flatpack keep it separate? I am told its not a good idea to mix two different installers...

I'm not sure what you mean by that?

Flatpak keeps its libraries separate from regular system libraries. They cannot mix. And you can install multiple versions of flatpaks and flatpak libraries. The only drawback is that they take a lot of space.
 

Offline WaveyDipole

  • Frequent Contributor
  • **
  • Posts: 851
  • Country: gb
Re: Open source lxi-tools v2.4 released
« Reply #73 on: December 21, 2022, 05:58:55 pm »
JohanH, thanks. I thought it would install the library onto my system like apt. If its kept separate then that's fine.

I tried the command as above but am still getting the same error message for that build step.
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6203
  • Country: ro
Re: Open source lxi-tools v2.4 released
« Reply #74 on: December 21, 2022, 06:00:24 pm »
Code: [Select]
lxi v1.21...
Which Linux distro are you using?

If a 'sudo apt update' then 'sudo apt install lxi-tools' still gives v1.21 it might be because Mint uses some older repos than the current Ubuntu.  Mine shows Ubuntu 22.04.1 LTS and lxi v2.1:
Code: [Select]
a@b:~$ lxi --version
lxi v2.1

a@b:~$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.1 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.1 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy
a@b:~$

Offline WaveyDipole

  • Frequent Contributor
  • **
  • Posts: 851
  • Country: gb
Re: Open source lxi-tools v2.4 released
« Reply #75 on: December 21, 2022, 06:13:07 pm »
Yes, it seems you are correct, although that does not surprise me:

Code: [Select]
$ cat /etc/os-release
NAME="Linux Mint"
VERSION="20.3 (Una)"
ID=linuxmint
ID_LIKE=ubuntu
PRETTY_NAME="Linux Mint 20.3"
VERSION_ID="20.3"
HOME_URL="https://www.linuxmint.com/"
SUPPORT_URL="https://forums.linuxmint.com/"
BUG_REPORT_URL="http://linuxmint-troubleshooting-guide.readthedocs.io/en/latest/"
PRIVACY_POLICY_URL="https://www.linuxmint.com/"
VERSION_CODENAME=una
UBUNTU_CODENAME=focal

Code: [Select]
$ cat /etc/upstream-release/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu Focal Fossa"

So yes, it is using an older repo which perhaps explains why so many packages are so far out of date...
 

Offline WaveyDipole

  • Frequent Contributor
  • **
  • Posts: 851
  • Country: gb
Re: Open source lxi-tools v2.4 released
« Reply #76 on: December 21, 2022, 06:36:17 pm »
Looks like it needed both:

Code: [Select]
flatpak install org.gnome.Sdk
flatpak install org.gnome.Platform

and selecting version 43 for each.

After running both installs, the build command finally worked. A bit of searching in the flatpak docsindicated that I could do:

Code: [Select]
flatpak run io.github.lxi-tools
and indeed, the GUI runs. I will test the the oscilloscope with it later.


« Last Edit: December 21, 2022, 07:14:04 pm by WaveyDipole »
 

Offline JohanH

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: fi
Re: Open source lxi-tools v2.4 released
« Reply #77 on: December 21, 2022, 07:34:09 pm »

Code: [Select]
flatpak run io.github.lxi-tools
and indeed, the GUI runs. I will test the the oscilloscope with it later.

On my system (Gnome/Fedora) I can also press the Win key, type "lxi" (and it will find the app from the installed applications and show the icon), press Enter and it runs.
 

Offline JohanH

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: fi
Re: Open source lxi-tools v2.4 released
« Reply #78 on: December 21, 2022, 07:36:43 pm »
Looks like it needed both:

Code: [Select]
flatpak install org.gnome.Sdk
flatpak install org.gnome.Platform

and selecting version 43 for each.


I forgot that I had installed these in the past (the platform certainly for some other application). I will update my previous post to include this if someone else finds the post.
 

Offline WaveyDipole

  • Frequent Contributor
  • **
  • Posts: 851
  • Country: gb
Re: Open source lxi-tools v2.4 released
« Reply #79 on: December 21, 2022, 08:48:15 pm »
Thanks for taking the trouble to update your post.

Unfortunately, having got this far, it seems that lxi-gui won't grab a screenshot from the MSO5074. The oscilloscope is correctly detected by the Search feature. However clicking Grab Screenshot returns Failure handling image format. The oscilloscope responds just fine to SCPI commands such as *IDN? and :SYSTem:VERSion? which shows there is communication over TCP/IP. Curiously, grabbing screenshots works fine when using the older 1.21 version of the command line tool so it seems a bit odd that the later version appears to  have problem with the image format. On the other hand its no listed as a supported device on the Github so please let me know if there are any diagnostics I can do. I would be happy to provide any data you require to help get this scope added to the list of supported devices.

I also tested the DS1054Z with version 2.4. This both responded to SCPI commands as well as requests top grab a screenshot and returned images. Version 2.4 seems to work OK with the DS1054Z.

Is it possible to run the lxi CLI tool from within the flatpak? I was thinking to check whether it is possible to grab a screenshot with this newer version via the command line.
« Last Edit: December 21, 2022, 09:16:32 pm by WaveyDipole »
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6203
  • Country: ro
Re: Open source lxi-tools v2.4 released
« Reply #80 on: December 21, 2022, 09:00:19 pm »
A very first test I would try would be to change the format of the screenshot, from the oscilloscope settings (if MSO5000 has such option, try BMP, PNG whatever MSO5000 has).

If you want to properly debug, install Wireshark and look at the LAN data packets sent by the v1.21, then compare that with what SCPI commands the GUI version sends (and the answer from the oscilloscope) while trying to get a screenshot.

Offline WaveyDipole

  • Frequent Contributor
  • **
  • Posts: 851
  • Country: gb
Re: Open source lxi-tools v2.4 released
« Reply #81 on: December 21, 2022, 09:28:39 pm »
RoGeorge, checking the display format was my first idea but I can find no option to change that on the scope. The only display setting there seems to be is to turn the HDMI display on and off and to set its resolution. I don't see any settings to change the format of the image data sent via SCPI. Of course, this may be possible even if via SCPI comands so I will check the manual.

The Wireshark capture was a good idea and I have done a capture of network traffic during a screen grab for each of the two versions. A cursory glance shows that both versions:

send - *IDN?
receive - RIGOL TECHNOLOGIES 5074,serial number,00.01.03.00.03
send - display:data? on,0,png

after which comes the image data.
« Last Edit: December 21, 2022, 09:55:27 pm by WaveyDipole »
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6203
  • Country: ro
Re: Open source lxi-tools v2.4 released
« Reply #82 on: December 21, 2022, 10:43:24 pm »
Not over SCPI, IIRC the setting is the one for when saving it on a USB drive.  Probably at page 349 of 372 (I've searched for 'jpg' inside the pdf, I didn't read properly so please double check, I don't have a MSO5000):
https://www.rigol-uk.co.uk/pdf/Rigol-MSO5000-User-Guide.pdf



So both the GUI and the command line are using the same SCPI?
Code: [Select]
:display:data? on,0,png
If yes, then it should work.  Try setting the image format to PNG in oscilloscope.  I don't know what to advice more without digging in the sources, sorry.

If you think you found a bug, please post it on github, so the devs will try to fix it.


LATER EDIT:
------------------
By looking at the programming guide for MSO5000, it says the returned format for the SCPI command ':display:data?' is BMP, and doesn't show the additional parameters 'on, 0, png', see page 88 of 282 in https://int.rigol.com/Images/MSO5000ProgrammingGuideEN_tcm7-4051.pdf

Yet you say the download screen works from the old command line 'lxi' but not from GUI, though both GUI and the command line are sending the same SCPI command.  That's contradictory, maybe you hit a bug, don't know what to advice further.  :-//

Ask lundmar here, or open a bug on github https://github.com/lxi-tools/lxi-tools
« Last Edit: December 21, 2022, 10:59:21 pm by RoGeorge »
 

Offline WaveyDipole

  • Frequent Contributor
  • **
  • Posts: 851
  • Country: gb
Re: Open source lxi-tools v2.4 released
« Reply #83 on: December 22, 2022, 08:03:24 am »
Thanks. I also had a poke around in the programming manuals for both the DS1054Z and the MSO5000. The DS1054Z manual contains a little more detail and shows the format of the image header. Both oscilloscopes are returning similar bitmap (BMP) headers, the only difference being is that the data length on the MSO5000 is larger since its screen has a higher resolution. I suspect that the 'on,0,png' parameter is just ignored by the scope.

The MSO5000 has several format options for saving data to USB including *.png, *.bmp, *.jpg and *.tif. By default, *.png is selected.

To confirm, yes, the download screen works from the old CLI command 'lxi' but not from the new version 2.4 GUI, though both GUI and the command line are sending the same SCPI command. I agree this sounds contradictory so I have now logged an issue for this at lundmar's GitHub repository as suggested.
« Last Edit: December 22, 2022, 08:08:04 am by WaveyDipole »
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6203
  • Country: ro
Re: Open source lxi-tools v2.4 released
« Reply #84 on: December 22, 2022, 08:29:03 am »
Yes, the TMC format is standard to exchange binary with SCPI (which otherwise are plain text messages).  TMC header stays the same even between different brands.

I doubt an incorrect SCPI will be ignored, but it could be an undocumented format of the command, or an incomplete programming guide (it happened before with my DS1054Z).

So, have you tested with each image format (by changing the image format in the oscilloscope), and none of the bmp/png/jpg/whatever format is understood by the GUI screen capture?
« Last Edit: December 22, 2022, 08:32:09 am by RoGeorge »
 

Offline WaveyDipole

  • Frequent Contributor
  • **
  • Posts: 851
  • Country: gb
Re: Open source lxi-tools v2.4 released
« Reply #85 on: December 22, 2022, 09:35:36 am »
Sorry, yes, I tested selecting each image format in Save Image->Format:. The result was always the same: Failure handling image format.
I also sent the command manually and it always returned the same header (#9001843254BM6....) regardless of image format selected, in other words, the image size always remained the same at 1,843,254 bytes. I agree, the part specified after the '?' might be an undocumented feature of the command. I hadn't considered that. The MSO5000 programming manual has very little to say on the subject of the DISPLAY:DATA? command and the DS1054Z manual diuscusses the command in more detail but does not mention any parameters.

« Last Edit: December 22, 2022, 10:10:26 am by WaveyDipole »
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6203
  • Country: ro
Re: Open source lxi-tools v2.4 released
« Reply #86 on: December 22, 2022, 10:04:23 am »
#9001843254BM6....

The #9 means the next 9 characters (001843254) will tell the length of the following binary data block.  BM6 are the first bytes from the screenshot (in text representation), BM6 means the picture format is .bmp, which is an uncompressed image format, so it will always have the same length for a given picture size.

If that always stays BM6 no matter the oscilloscope format settings, it means it always sends a .bmp, while the application expects a .png (judging by the SCPI command containing a png request).  Sounds like a bug.

The receiver GUI would be able to detect the encoding by looking at the first data bytes, though I don't know if format detection is the pillow lib's job (or whatever other library the GUI may use), or if the format detection must be dealt with in the GUI code before converting it with a lib.  Maybe the SCPI command for MSO5000 must be changed, too, so the GUI will not assume a PNG, and look at the first bytes of the data to properly identify the format.

Seems clear what is happening, but I'm not familiar with that part of the code so I can not tell the proper fix.  :-\
« Last Edit: December 22, 2022, 10:09:06 am by RoGeorge »
 

Offline WaveyDipole

  • Frequent Contributor
  • **
  • Posts: 851
  • Country: gb
Re: Open source lxi-tools v2.4 released
« Reply #87 on: December 22, 2022, 10:10:14 am »
You appear to be on the right track though. I captured a Wireshark dump of the same command being run on the DS1054Z to determine what actually IS being returned from this scope, as opposed to what the manual says. This is what appears in the output (partial packet contents extracted as printable text):

Code: [Select]
#9000031650PNG

IHDR àÒe¢ tEXtAuthorRIGOLÒe¢tEXtSourceDSZ seriesÒe¢)tEXtDescriptionDSZ_Printing equipment outputÒe¢tEXtCopyrightRIGOL TECHNOLOGIESÒe¢z×IDATxí½/¼#W+P A

So it seems that on the DS1054Z, the 'n,0,png' is valid (as well as apparently undocumented) and does cause the image data to be returned in PNG format. The MSO5000 does not respond to those parameters and is sending the data in BMP format. It would seem that those parameters are either not implemented on the MSO5000 or perhaps take a different form. However, this still does not explain why lxi version 1.21 works...

I have updated the issue that I logged earlier with this additional information. I will also look into whether the format of the data being sent via SCPI can be changed on the MSO5000.

« Last Edit: December 22, 2022, 10:22:57 am by WaveyDipole »
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6203
  • Country: ro
Re: Open source lxi-tools v2.4 released
« Reply #88 on: December 22, 2022, 10:17:22 am »
My guess is lxi v1.21 properly looks at the answer and detect the format, while the newer ones wrongly assume the returned image is what was requested by the SCPI command, a PNG.  Or maybe the v1.21 is using some older libs format image manipulation, and those older libs were properly detecting the format by looking at the first data bytes, while the newer libs do not autodetect the format.

These are just guesses, only the devs can tell for sure, or yourself if you look at the github sources and compare the two versions.
« Last Edit: December 22, 2022, 10:19:45 am by RoGeorge »
 

Offline WaveyDipole

  • Frequent Contributor
  • **
  • Posts: 851
  • Country: gb
Re: Open source lxi-tools v2.4 released
« Reply #89 on: December 23, 2022, 05:47:24 pm »
With the kind support of the lxi-tools developer, this now appears to be fixed and lxi-gui can now grab screenshots from my MSO5074.

https://github.com/lxi-tools/lxi-tools/issues/63

The problem seems to have affected only the flatpak build.
« Last Edit: December 23, 2022, 06:57:15 pm by WaveyDipole »
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6203
  • Country: ro
Re: Open source lxi-tools v2.4 released
« Reply #90 on: December 23, 2022, 07:03:55 pm »
Good to hear it's now fixed, well done for reporting the bug, and thank you devs for the fix!  :-+

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.4 released
« Reply #91 on: December 25, 2022, 03:07:18 pm »
Good to hear it's now fixed, well done for reporting the bug, and thank you devs for the fix!  :-+

No worries. Happy holidays everyone!
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 
The following users thanked this post: RoGeorge

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.4 released
« Reply #92 on: February 22, 2023, 12:24:46 pm »
lxi-tools v2.5 has been released:

https://github.com/lxi-tools/lxi-tools/releases/tag/v2.5

Changes since lxi-tools v2.4:

 * Add new screenshot plugins

   Add screenshot plugins to support:

    * Tektronix MSO 5 series
    * Rohde & Schwarz RTH series (hand help oscillopes)

 * Add code for backwards compatibility with lua 5.0/5.1

Twilight-Logic:

 * Updated rigol-2000 plugin to allow screenshot capture on MSO5000
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 
The following users thanked this post: RoGeorge

Offline Neuromodulator

  • Regular Contributor
  • *
  • Posts: 67
  • Country: cl
Re: Open source lxi-tools v2.0 released
« Reply #93 on: June 14, 2023, 04:04:05 am »
Can the liblxi be used to develop LXI devices?

I know, that lxi tools was developed as a LXI host, to connect with LXI devices. But I thought, that liblxi contains all the functionality to support both the host side as well as the device side. So, would it be possible to expose ADCs/DACs on a Raspberry Pi (maybe from a HAT) as an LXI instrument, with the liblxi?

That would be very good, to one central LXI host and device code base.

I'm on the same boat, I want to add VXI-11 connectivity to a device that I'm developing. What libraries did you end up using?
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.5 released
« Reply #94 on: August 08, 2023, 06:52:19 am »
FYI - lxi-tools v2.6 is available and it now supports macOS via Homebrew:

Code: [Select]
brew install lxi-tools


Changes since lxi-tools v2.5:

    Update postinstall.py to use gtk4-update-icon-cache

    Use gtk4-update-icon-cache instead of gtk-update-icon-cache which is
    only for gtk3.

    Add Rigol MSO4024/4054 to list of supported instruments

    Add screenshot support for Rigol DS4000 series

    Add screenshot plugin support for Rigol MSO5000 series

« Last Edit: August 08, 2023, 10:09:34 am by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 
The following users thanked this post: phs

Offline lambcutlet

  • Contributor
  • Posts: 13
  • Country: gb
Re: Open source lxi-tools v2.6 released
« Reply #95 on: August 16, 2023, 09:52:38 pm »
Hi Lundmar,

Could you help with some lxi-tools script syntax?
I don't want to double post so here's a link, thanks
https://www.eevblog.com/forum/testgear/lxi-tools-tti-pl303qmd-p-connection-help-required/

 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.6 released
« Reply #96 on: August 19, 2023, 02:32:23 pm »
Hi Lundmar,

Could you help with some lxi-tools script syntax?
I don't want to double post so here's a link, thanks
https://www.eevblog.com/forum/testgear/lxi-tools-tti-pl303qmd-p-connection-help-required/

Sure - I'll take a look.
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.7 released
« Reply #97 on: August 19, 2023, 04:13:44 pm »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 
The following users thanked this post: MegaVolt, dibro

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.7 released
« Reply #98 on: August 19, 2023, 04:18:52 pm »
FYI - we are aware there are some issues with the Homebrew package if you are trying to run lxi-gui on MacOS.

An updated Homebrew package which fixes any issues should soon be available.
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.7 released
« Reply #99 on: August 22, 2023, 07:08:10 am »
FYI - lxi-tools v2.7 is now available for MacOS too:

https://formulae.brew.sh/formula/lxi-tools

This new Homebrew formula should install fine without any workarounds.
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline bicycleguy

  • Frequent Contributor
  • **
  • Posts: 265
  • Country: us
Re: Open source lxi-tools v2.7 released
« Reply #100 on: August 23, 2023, 08:52:48 pm »
FYI  was able to install lxi-tools v2.7 from brew as in last post on a M2 MacBook Air.  It had a few error messages suggesting updating stuff I already had, including Xcode tools and Python2 which I didn't do as I'm Python3.  With that, I was surprised it seems to work.

I use mostly for TestController.
 
The following users thanked this post: lundmar

Offline dobsonr741

  • Frequent Contributor
  • **
  • Posts: 674
  • Country: us
Re: Open source lxi-tools v2.7 released
« Reply #101 on: February 03, 2024, 10:43:34 pm »
Quote
Can the liblxi be used to develop LXI devices?

I know, that lxi tools was developed as a LXI host, to connect with LXI devices. But I thought, that liblxi contains all the functionality to support both the host side as well as the device side. So, would it be possible to expose ADCs/DACs on a Raspberry Pi (maybe from a HAT) as an LXI instrument, with the liblxi?

That would be very good, to one central LXI host and device code base.

I'm on the same boat, I want to add VXI-11 connectivity to a device that I'm developing. What libraries did you end up using?

Would anyone be able make progress on creating LXI devices?
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools v2.7 released
« Reply #102 on: March 27, 2024, 07:40:54 pm »
Quote
Can the liblxi be used to develop LXI devices?

I know, that lxi tools was developed as a LXI host, to connect with LXI devices. But I thought, that liblxi contains all the functionality to support both the host side as well as the device side. So, would it be possible to expose ADCs/DACs on a Raspberry Pi (maybe from a HAT) as an LXI instrument, with the liblxi?

That would be very good, to one central LXI host and device code base.

I'm on the same boat, I want to add VXI-11 connectivity to a device that I'm developing. What libraries did you end up using?

Would anyone be able make progress on creating LXI devices?

Yes, I am planning to release both VXI11 and HiSlip server implementations in C as open source.
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 
The following users thanked this post: RoGeorge, MegaVolt


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf