Certainly. And anyone is welcome to do that to accommodate their personal need. I have no way to test that at the moment and I'd prefer to rework the patch to make it more general and easier to maintain going forward. There's no chance the patch will be accepted as is and that is part of the reason why. Ultimately it would be nice to have it merged if for no other reason than not having to maintain it outside of sigrok.
Hi Spike, are you still working on this ?
I've been trying to accommodate the original Pull Request to work with the SDS2000X-HD.
I agree with you, the orignal PR is quite a mess and needs a lot of rework, I understand why it has not been accepted by the maintainers of Sigrok codebase.
Maybe we can join efforts ? What Siglent model do you have ?
Right now I have both analog and digital signal capture working with a given time-base. Next step is to have everything work fine when changing settings.
Best,
Frederic.
As I’ve said above, until I get a device in hand there’s not much I can do and based on estimates I don’t expect to have one for at least a month. If anyone has code that can possibly get merged then absolutely go for it. I’ll do what I can to help but probably won’t be immediately.
I have some additional comments about other posts in this thread but I’m on vacation at the moment and typing this on a phone is quite annoying. I’m back tomorrow.
I'm back and caught up. A few comments below
just 2 cents worth, but if you guys managed to become spark plugs that get Sigrok on a path to playing nicely/increasingly well with Siglent oscilloscopes, especially the HDs, it could be a significant win for Siglent users, Siglent, and maybe even Sigrok… which could be a win for more device manufacturers and more users
This would be great for sure, but I'm a bit of a pessimist and I don't know how much optimism I can muster for such a scenario. I don't think there's really any development to spark. It seems that there is very little activity.
I'm far from an expert on the internals of sigrok, I'm just getting started poking around. From what I can see, though, it appears that for many device families the support for all devices in the family reside in a single "module". This means that whenever someone tries to add support for new devices they have to tiptoe around existing devices and there seem to be more than a couple of examples of patches sitting in limbo for years because of (legitimate) concerns about breakage of existing devices. In most cases the author of the patch has no way to test this because he doesn't own any of the other devices. I'm all for code reuse but it seems to me that this is increasingly causing a support burden
The bigger problem, IMO, is that the way that device support is delivered is that it is committed to the libsigrok codebase and built into a monolithic library. So any time new hardware support is desired it must go through an increasingly slow merge process. This is not conducive to new hardware support and I think that adding devices will get harder and harder going forward. If there's even anyone to review patches.
What I would prefer to have is some sort of dynamic loader in the hardware API code and some way to separately build loadable modules that conform to whatever the current API is. Even if the API is not moving or being actively maintained as appears to be the case now, at least folks would have a shot at building a working module for a new device without needing to merge it into sigrok.
Of course all this is work and it does not appear that there is a critical mass of developers on the project to keep it going.