hckrnws
Sigrok – a portable, cross-platform, FOSS signal analysis software suite
by _Microft
I don't know. My experience as a contributor to Sigrok was sad: I significantly improved a driver and wanted to upstream those changes, but was met with "well, the maintainer has little time, can you slice your changes into smaller pieces?", and honestly, after a months of doing that, waiting weeks for feedback, explaining things, I lost interest. Also, with time, I honestly don't remember some details of the changes beyond what's in the commit messages.
I also found the style of the code quite antiquated, without any wish to change that. But that's my taste.
So, in the end, my work on that driver felt wasted.
Your OLS improvement patch set was huge, and a challenge for anyone to review. But you're right that it took much too long to get any traction, and I don't blame you for getting discouraged.
Having said that, you did eventually get a ton of comments, by a trusted and well-respected contributor (wsa), but I guess you'd already given up by then, so didn't respond.
How about this: make the changes requested, and I'll personally take on further review and/or approval. I'm the original author of the OLS driver, and of course I have the hardware, so that's as good an opportunity to get your code in as you'll get.
Oh, thank you for the offer! I'll pick it up again and update the PR. Haven't looked into it since then.
I found the OLS, especially with the Demon Core, a really neat piece of hardware.
"can you slice your changes into smaller pieces?"
You don't send a huge patch to a project as a first time contributor.
I am sure sigrok would benefit from your improvements, but sometimes the maintainer has a busy life outside the project so you need to adapt to their pace, at least in the beginning.
I would agree without even the caveat of the maintainer being busy. When a maintainer receives a massive changeset they have to then recover why the task was taken on in the first place and understand any decisions to get to the same outcome presented in the changeset provided. The more logical complexity that this change represents whether it is 3 lines or 3000 lines still needs to be understood by the reviewer as not breaking the rest of the system and equally can be 'massive.' The further you get from an N+1 change into a N+5 or N+6 change is where you get into situations where a N+3 change is flawed based on the rest of the system and invalidates large parts of the changeset, and that doesn't resolve all the issues or concerns.
I think a lot of people forget that changesets are sometimes not the most straightforward way to express ideas. They (including myself) also forget that while you are working with a change in front of you it's obvious but in one month it could be opaque. A maintainer is often giving you the perspective of you a month later who built on this system you changed.
For something like drivers most of them are probably from first time contributors, and they aren't really going to be hanging around for further contributions.
That's fine - the driver would improve if the contributions are accepted, and they don't touch core code that will break other things. But instead totally non-functional drivers are left languishing because PRs aren't merged.
In the case of Sigrok the problem didn't seem so much the maintainers, but rather non-developers "triaging" PRs with unhelpful advice to split patches, when a lack of actual developers meant they'd never be looked at anyway. Otherwise a fork might have occurred rather than wasting everyone's time.
I wish projects would be more strategic around acceptance rates on drivers/plugins contra core. On plugins etc one should have much lower barriers to contributions, compared to on the core. It is actually one of the primary reasons why such architectures are beneficial in FOSS projects.
> You don't send a huge patch to a project as a first time contributor.
Although that’s a good guideline, it’s not true in absolute terms. Sometimes the contribution is a big patch!
And sometimes the best way to contribute is by forking. Depends on the situation for sure, but this encourages an acceleration by the maintainers of the original library. If they don't have the time to do so, they can comfortably ignore the fork.
On GitHub most PRs come from works though? Or do you mean make an entirely separate driver?
I do appreciate your contribution but I'd also like you to ask for some understanding of the project's struggle as well. Aside from the loss of members due to personal interests shifting, the project has to make sure that all changes do not introduce regressions. We do not possess all the hardware that the drivers support, so when someone wants to change the code that affects multiple devices, we have to be very careful and thorough to make sure that these changes don't make other devices supported by that driver stop working.
Sometimes, when the changes are too big to make a decision by code review alone, we need to rely on user feedback. Unfortunately, this is always a challenge as there aren't a lot of users around who are willing to test changes.
I hope to improve the situation by allowing the CI/CD pipeline to provide binaries for PRs so users don't have to build from source.
Either way, your efforts aren't wasted and I appreciate anyone wanting to help out.
Sigrok project is dead... There is a single maintainer and he's not willing to merge almost anything, it's been like that for years. I think it's time to fork...
While I acknowledge that the project was without effective leadership over the past 2 years, I'd appreciate if you wouldn't mix up "willingness to merge" with the ability to do so.
There are a lot of pending changes that I simply cannot review or verify easily since I don't have the hardware the driver is written for. Asking for help has never really been met with much enthusiasm, unfortunately.
Either way, I'll get to these as soon as I can and help is definitely welcome.
My experience using sigrok with cheap fx2 based logic analyzer hardware was great, and I heavily recommend it. My experience using it as a GUI for an oscilloscope was less impressive (it wasn't so interactive).
The next time I need my oscilloscope, I want to take a few moments to try out https://www.ngscopeclient.org/
I will never understand this. libsigrok (the driver backend) supports over 130 oscilloscope models. Why not just write a GUI that uses libsigrok, and instantly get access to all of those?
edit: actually I think that's azonenberg's project. IIRC I discussed it with him once, and the reason was licensing, not technical.
This looks interesting. I wanted to try it with my Rigol DS1054Z, but there is no AUR package for Arch Linux for it, which makes the installation cumbersome. The user experience with Sigrok is superior in that aspect ;)
I hate to sound like the classic Arch user, but if you're unable to build packages from source I'd highly suggest a different distro. Being a rolling release things will break. I've been a daily Linux driver for over a decade and do live Arch, but it's not for noobs unless you're willing to dive into the deep end (in which case it's great, but because breaking becomes a feature instead of a bug lol)
If you have not already done do, I highly suggest installing timeshift[0] and the associated pacman hook[1]. Make sure to appropriately configure them and setup good timers. This will save you a lot of headaches, especially if you have an Nvidia GPU (Jensen please...)
this comment is a masterclass in advertising
start relatable: “my experience” add reinforcing detail: works well with fx2 hw add negative experience: bad for analog logic introduce habit trigger: next time use ngscopeclient for analog logic
I'm a bit confused, is the implication that they're shilling for ngscopeclient or something? It's not a paid product (neither is sigrok). They're not wrong either, Pulseview (sigrok) is great doesn't feel very designed for interactive use from the little bit I played with it.
Either way it is great marketing. Maybe they just have a knack for it!
Maybe they just use LLM to proof their comments. You too can sound like dismissible ad copy with this one simple trick!
I didn't use an LLM, but on rereading in the morning, I am cringing at "wasn't so interactive", so maybe I should have. There had to be a better way to put my complaint.
It's fine, we will all be suspected of being LLMs now. :)
With the right hardware this might work for you: https://github.com/OpenHantek/OpenHantek6022
I am still waiting for my driver to be merged :-(
Quite a useful tool! I was trying to build an IR remote converter and I wrote a custom protocol decoder for sigrok to help compare the incoming signal and what my code was producing. Very useful debugging tool. Quite powerful with the cheap salae knockoffs
Sigrok is a really valuable project. Thanks!
The greatest issue I see is that this is a fairly niche field for open source software historically due to the difficulty of acquiring the actual logic analyzers for a personal or student lab at times. People in general see older projects as establish and will often guide their focus to their own greenfield interests.
There are now a growing number of people entering this area of development however and more projects are being founded every month as availability and support for good-quality, stable hardware is increasing!
This is an exciting time for open source analysis, and given the availability and maturity of older 24mhz logic analyzers, on-demand manufacturing and supporting protects (kicad) I expect this to continue.
Hopefully sigrok takes on some new contributors who can engender even greater cooperation from this extremely relevant and exciting project!
For me PulseView unfortunately has been very buggy and I never really got it to work (neither with an old Saleae 8, a new Saleae Pro 16, or an FX2 clone) well and without constant crashes.
I tried on Linux & mac, but never could get it to run well. I'd be super curious to chat with someone who had a different experience on what you've been doing differently from me!
I love the idea of Sigrok, so would love to get it to work (well) for me
PulseView shouldn't be crashing a lot at all, honestly. Were you running the nightly or the 0.4.2 release? The 0.4.2 release is rather outdated, I'm working on making a new release soon to fix that.
Not my experience. I got a cheap Sparkfun logic analyzer on a whim and it sat idle until I had a work problem that I spent a lot of WFH time debugging with it using Pulseview.
I later recommended that we buy a Saleae analyzer just in case the SF one was hiding a problem and I didn't find any substantive difference between the two.
It is my firm belief that everybody should have one of those $10 FX2 boards in their drawer, either for debugging some electronics board stuff (arduino and up), or just for learning about digital signalling. $10 and Pulseview is all you need!
Sigrok wiki is a great source to check for protocol documentation of measuring device.
Wow, cool to see Sigrok here, I wonder if there was some particular "trigger" story or how that happened. Glad to think that there will be many "lucky 10,000" [1] today.
I haven't used it in years, but I clicked back to the first devlist email I had, and it seems that was from 2010. Wow. It's really old and feels well established, a great success!
No idea how live it is as an open source project, I have to check out the current status.
They don't seem to be too interested in releases. Their git is sadly gitweb, which isn't something I love seeing, but the main parts appear to have activity this year.
The current sigrok maintainer is trying to take part in this discussion (username abraxa), and is in general trying to reinvigorate the project.
However, one or more of you idiots keeps downvoting every single one of his comments, and they're all marked dead, and invisible.
I think i figured it out and i blame my illness for my failing to realize... it's september. HN comments have been upside-down world for a few weeks now. I just assumed my brain was having slight issues with comprehension and understanding how i was presenting my ideas; while that may perhaps be part of it, i don't think it's the full story.
I don't think i've used sigrok (or the other product mentioned around here), but i do have one of those usb oscopes and now i want to check it [sigrok] out. Whenever i see a bunch of people bellyaching about free software i gotta try it out - it usually ends up a permanent part of my toolkit.
thanks for replying, and i hope the maintainer gets their comments undeaded.
Email hn@ycombinator.com. I wonder if abraxa's account tripped some spam filter or something. The mods should be able to help.
Edit: I sent the email myself.
Sigrok is awesome. The pulseview UI is pretty much perfect for configuring decoders
The only downside is the stability issues (fast crash to desktop). Happens pretty much every time I use it. Still the best tool of its kind
PulseView shouldn't be crashing a lot at all, honestly. Were you running the nightly or the 0.4.2 release? The 0.4.2 release is rather outdated, I'm working on making a new release soon to fix that.
I tried some different versions and ended building from source. Currently on commit ls from the 14th of march
The most consistently crashing behavior has been when trying to import or work with csv or vcd data (pure 0/1 data)
Sigrok is amazing! The killer feature for me is sigrok-cli. With it you basically convert from electrical signal to Unix pipe.
Super useful for running e.g. timing measurements and quick-and-dirty plotting. Or grepping through millions of signal transitions to pin down a nasty race condition.
There's a lot of complaints here about how slow the project is and that it's single maintainer, but also how valuable and useful it is
Is this a funding problem?
Do we need to have the xz conversation again?
I really do love OSS but we need to figure out something where valuable projects aren't just hobbies or side projects (not even a side hustle). With all this time can we not improve on our model? To get funding where it's needed? This is also a friendly reminder than most big tech companies will donation match, so maybe send $5 to a few of your favorite projects. You're making big money now, you can buy a few beers for you friend (and put a few on the company's dime).
Honestly, it's a general FOSS problem in my opinion. sigrok is rather niche and spans a wide skill set across the various sub-projects. We have C code for 8051 for fx2lafw, we have C code for libsigrok, C++ code for PulseView, C and python for libsigrokdecode, and so on. There are plenty of people who drop off patches and move on but finding people who are willing to stay and take ownership of something is a challenge.
Money would only help insofar as it would allow me to buy hardware I could test drivers with. However, I don't have the space for such equipment and even a simple scope costs so much that it would probably eat up a year of donations.
I appreciate your thoughtfulness, though. In the end, all I ask is for contributors to see things from the project's point of view and try to make things as easy as possible. I hope that more people will join our efforts once the project has more visible signs of life again.
> it's a general FOSS problem
Yes, I agree. The FOSS model doesn't seem to be working even though I believe it can. So I still will try to rally people to chip in here and there. I think many devs are happy to work on their projects even without huge tech salaries and many small contributions can add up. So it is a win for everyone (I think I'm a bit surprised -- not really -- that the EA people don't advocate for more FOSS donating).But I do think this is in part related to the "staying around" issue. No one wants to do the boring stuff and it's easier to just give people a salary and throw that under their umbrella. Hard to justify this in volunteer work.
I do wish we would have a real conversation about this on HN and we could actually dig deep into it. But I think it is easy to think it is not a problem because things appear to be working smoothly, so cracks are easy to ignore and it is easy to not think about if we could be more efficient. I definitely don't know a solution to the problem but I'm sure given some time there's more than enough smart people around here that understand different aspects of the problem that it could be solved.
That said, I do personally appreciate your project, and have recently gotten into some hardware hacking (need to fix some devices...). And I hope you focus more on the encouragement in the thread over the criticism (even though some is valid, constraints matter).
On a completely different note, is there any plans for a full TUI? Or someone that is doing this?
> On a completely different note, is there any plans for a full TUI? Or someone that is doing this?
What's a TUI here? sigrok-cli can do everything the backend libs do, or do you mean some more interactive text client?
Thank you for your commentary!
> Is this a funding problem?
No.
Why?
Anyone tried both this and QCoDeS? We use QCoDeS in our lab after deciding Keysight's Labber wasn't tenable, and I'm curious how they compare.
Crafted by Rajat
Source Code