EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: shirsch on June 16, 2021, 02:54:41 pm
-
I have just started using Sigrok with a Hantek 4032L logic analyzer and am running into some very fundamental issues. The maintainers do not seem responsive to Bugzilla posts, so perhaps they are dismissing me as an inexperienced user (?). Before I try again, I'm wondering if I'm the only one seeing the problems:
- Data captures and sessions are not retaining row order or grouping after save and reload
- Decoder and decoder configuration are not properly retained over session save and reload
- On Linux, successive save and reload of session adds geometrically expanding numbers of decoders
- Trigger configuration is not retained over save and reload
None of these are fatal bugs, but all are serious annoyances and time wasters. I'm seeing them on box Linux and Windows builds (my build on Linux, pre-compiled binary on Windows). Haven't tried Mac yet.
-
The maintainers do not seem responsive to Bugzilla posts, so perhaps they are dismissing me as an inexperienced user (?). Before I try again, I'm wondering if I'm the only one seeing the problems:
I doubt that.
The whole project is a brute force hack without a single bit of
manufacturer contribution...
Considering the "usable" status of several devices..
..and the "on going" status of others...
I would say they achieved a remarkable work.
OSS folks do that on "per possible means.."
and "I need that working.." usually
So never expect someone on the the wire doing that
for kicks.. in time critical bugs are solved as possible..
If you can do any thing to actually send a patch..
it should be read with more interest than just "hey here a bug"
Every OSS folk knows there are plenty of them..
we (myself included) just try to solve or live w/them
Paul
-
Ok, fair enough. But, even for an OSS project there seem to be a lot of fundamental issues for code that's been worked on for almost 10 years. I was not using this forum to complain, but to get level-set about actual issues vs. issues that sit between chair and keyboard.
Much as I'd love to contribute, complex QT-based GUI code is well out of my comfort range. I'll just hope the problems I mentioned are either (a) operator error or (b) get addressed in the near future.
-
The maintainers do not seem responsive to Bugzilla posts, so perhaps they are dismissing me as an inexperienced user (?).
Keep in mind, Sigrok is mostly, or exclusively, built by volunteers working on their on time. These people have day jobs, families, etc. competing for their time and attention. They are also likely spread all over the world, in different time zones, etc. So don't (necessarily) expect the kind of service you get if you have a Double Platinum Exclusive Premier Enterprise support contract with Keysight or somebody. This open source stuff is pretty much all "best effort" on the part of the maintainers.
-
Complain is also a very important part of that..
When done with a solution or patch is better..
Probably this device has several pending issues
like many others on the site.. awaiting time
resources and patience..
Bottom line is that software moves way too fast...
I yet to see a bundle without problems..
some got solved.. others kick in..
That is part of it.
Paul
-
Sure, but it would still be valuable to know if anyone else is seeing the issue. I understand completely about supporting numerous different devices, but it's hard to see what is device specific about the problems I related. Once the data is captured (which is being done correctly), it becomes canonical in Pulseview's internal format. It is that format that apparently fails to preserve session semantics.
In any event, I'm completely realistic about OSS projects and do NOT expect instant gratification or bug fixes. My primary aim in posting here was - and remains - to learn if others are experiencing loss of session setup. It's quite possible (actually, likely) that I'm misunderstanding the operation of the tool. There is no point in engaging on Bugzilla if the problem is isolated to one user.
-
My primary aim in posting here was - and remains - to learn if others are experiencing loss of session setup. It's quite possible (actually, likely) that I'm misunderstanding the operation of the tool. There is no point in engaging on Bugzilla if the problem is isolated to one user.
I can try testing that later, maybe this evening after work.
-
Tried saving a session with the latest windows version 0.5.0, it just gets stuck on "saving" window and never completes.
However, if I go to "Save Session Setup" under the save menu, I can save the pvs file only.
After going to "Restore Session Setup" the decoder with its settings is back. The trigger settings are lost.
If I do "Restore Session Setup" twice, or after auto load, then it will double the decoders seen as you say. Almost as if its not clearing the existing settings before loading new ones.
-
Tried saving a session with the latest windows version 0.5.0, it just gets stuck on "saving" window and never completes.
However, if I go to "Save Session Setup" under the save menu, I can save the pvs file only.
After going to "Restore Session Setup" the decoder with its settings is back. The trigger settings are lost.
If I do "Restore Session Setup" twice, or after auto load, then it will double the decoders seen as you say. Almost as if its not clearing the existing settings before loading new ones.
It actually does save the data, but the dialog doesn't cancel on its own. That particular issue is a recognized bug in their system. But, I think you'll find that reloading the saved .sr file scrambles 'A' and 'B' signals together, destroying the original row ordering. They can be dragged back to the right places, but it gets old quickly with 32 channels active.
If you can try reloading the saved data it would be a simple way to see if it occurs.
-
It actually does save the data, but the dialog doesn't cancel on its own. That particular issue is a recognized bug in their system. But, I think you'll find that reloading the saved .sr file scrambles 'A' and 'B' signals together, destroying the original row ordering. They can be dragged back to the right places, but it gets old quickly with 32 channels active.
If you can try reloading the saved data it would be a simple way to see if it occurs.
Yes row ordering, probably part of whatever holds settings for triggers, is also lost.
edit: if you look at the pvs file, it is saving in the order of D0, D1, etc. no matter what. So either: the ordering is missed when its saved, or another field needs to be added to define the ordering in addition to just its position in the psv file.
edit: somewhere in here https://github.com/sigrokproject/pulseview/blob/master/pv/storesession.cpp ?
-
It actually does save the data, but the dialog doesn't cancel on its own. That particular issue is a recognized bug in their system. But, I think you'll find that reloading the saved .sr file scrambles 'A' and 'B' signals together, destroying the original row ordering. They can be dragged back to the right places, but it gets old quickly with 32 channels active.
If you can try reloading the saved data it would be a simple way to see if it occurs.
Yes row ordering, probably part of whatever holds settings for triggers, is also lost.
edit: if you look at the pvs file, it is saving in the order of D0, D1, etc. no matter what. So either: the ordering is missed when its saved, or another field needs to be added to define the ordering in addition to just its position in the psv file.
edit: somewhere in here https://github.com/sigrokproject/pulseview/blob/master/pv/storesession.cpp ?
Thanks for confirming the issue! Now that I know it's not operator error I will dive into the code and see if anything jumps out. Very unfamiliar with Qt, but it's well documented with many tutorials.