On Sat, 2021-07-03 at 19:16 +0100, Martin Ling wrote:
>
> On Sat, Jul 03, 2021 at 04:49:34PM +0200, Gerhard Sittig wrote:
> > On Thu, 2021-07-01 at 23:44 +0100, Martin Ling wrote:
> > >
> > > The current architecture of libsigrok makes this difficult at the
> > > moment. Please see the following bugzilla entry for some previous
> > > thoughts on this:
> > > https://sigrok.org/bugzilla/show_bug.cgi?id=1276
> >
> > Don't think that this is related (the Bugzilla item that you
> > reference above is about unified or common SCPI device
> > identification, which is totally not the issue here).
>
> It is very relevant in my view.
>
> From the point of view of a Fluke 45 user, the potential pitfall of the
> local echo feature was previously detected and addressed by the driver.
>
> [ ... more on SCPI device detection ... ]
Martin, have you seen the "sigrok-cli & Fluke 45 DMM question"
thread which started on 2021-05-31? You can trust me that I'm
well aware of the history and motivation of what you say there.
It's not that I would not understand. It's instead that the
information in that thread let me conclude that device
identification really is not the issue here in this specific
case. Which was as unexpected to me, but it's the essence of that
thread.
All the information that has been available so far resulted in
the current mainline implementation of that fluke-45 driver. The
most recent commit being a36b21fb89ca which I specifically
quoted. Inluding its discussion of which behaviour one should
expect, based on the information that was available at the time.
The idea is that either the echo is off, and allows successful
identification and use of the device. Or echo is on, breaks the
identification, won't even start measurements, while user visible
logs of device communication strongly suggest why identification
failed: The response would be a reflection of the request, rather
different from any expectation of an identification response,
leaving a rather strong hint towards the cause.
But here is the surprise: The most recent user feedback suggests
(not verified yet) that with echo enabled in the device the
idenfication _passes_, while taking _measurements_ fails. This is
something totally new, has not been in developers' awareness
before, and was described by the user in words but is not backed
by log information.
Given that neither the original driver author nor any maintainer
nor any other active developer has that device and no other user
has chimed in, the reporting user's information is the only thing
which could result in progress here. Without that information we
are stuck with guessing. That information is so essential to
developers, and is available to the user. (See the thread, it's
not like getting a log is difficult or impossible, it _is_ there
and sits on Stuart's disk.) The desire to see that very data and
not an interpretation of it was communicated several times in
different levels of severity. And the user intentionally chose to
not provide it on several occassions even after severely repeated
requests to see that very information. Because? I don't know the
reason. Because it would be a helpful thing to do? Because those
people who tried to help asked for it? Because it could help all
other future users of that device including Stuart himself, and
you cannot allow that to happen? I don't know, and I seriously
don't get that reasoning. And cannot think of any other valid
excuse for not providing the one essential thing that is needed
and is available and is easy to provide. My frustration
originates from the inability to communicate such a simple and
actually obvious thing as "SHOW THE DAMN LOG ALREADY!". :-[ And
without that log nothing useful can be done, and we are forced
to stick with that situation. It's such a pity.
I still believe that the current implementation of the driver
allows to handle the situation which is seen when echo is enabled
in the device. In ways that are either fully transparent, or at
least helpful to users by immediately pointing to the cause of
the failure. It's just that whoever attempts to improve the
driver needs the very information on what device communication
looks like in that situation. And common identification including
reduced amounts of IDN queries or special treatment of specific
transports is orthogonal to that aspect, and would not affect the
driver's behaviour either (only beneficial, not undesirably).
virtually yours
Gerhard Sittig
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
