Hi @Soeren, all,
Many, many thanks for the answers - they were immensely helpful for me!
The range of the data type you use (0..255 for u8) is mapped to the
voltage range of -0.5V and +0.5V, as you noticed. That is not done
within PulseView, it's a property of the input module raw_analog.
See
https://sigrok.org/gitweb/?p=libsigrok.git;a=blob;f=src/input/raw_analog.c;hb=HEAD#l55
Fantastic, thanks for this - it would have taken me forever to figure out where
this definition was, otherwise!
* When I use Sample rate (Hz): 0, PulseView seemingly choses 10 ms
as sample period by default. Why is this number chosen, and is this
documented anywhere? (I expect if I enter a proper sampling rate,
then I'll get the corresponding sampling period instead).
That's not the behavior I see. For me, using a sample rate of 0 results
in PV using samples as the measurement scale, as indicated by the "sa"
unit shown in the timeline. In this case, any protocol decoder can't
give proper timing information and actually shouldn't.
How did you come to the conclusion that 10 ms sample period is used?
I came to that conclusion, because when I tried the experiment described in
https://electronics.stackexchange.com/questions/426287 - I captured it on an
image, this one:
https://i.stack.imgur.com/jO5mf.png
... and there I can see the timeline in ms; and I can count approx 10 samples
between 0 and 100 ms, and thus I arrived at 10 ms sampling rate.
However, that experiment was done with pulseview-0.4.1-64bit-static-release-installer.exe
- in the meantime, I overwrote that and installed a nightly, which apparently installed
version 0.5.0-git-58cd5b5 - and indeed, when I try the same experiment in that version,
then I have timeline in units of "sa" (samples):
https://i.stack.imgur.com/SgfKv.png
So that solves this issue for me now - thanks a lot for this! I will integrate
these answers in the EL.SE post ...
* Does PulseView have any kind of support for Hi-Z as a logic state
(in VCD or not)?
As of now it doesn't, it only supports 1 and 0. In the future we do
want to support all the other states but currently, that would be a
huge impact on performance, so we need to rework the inner workings
before this can happen.
Great to have this explicitly stated - thanks!
* If not, is there a "cheap" way for me to quickly implement it (e.g.
maybe there is an enum or something I could change in the source, so
that Z would be interpreted from a VCD file as its own state; or
maybe I could add another threshold conversion algo, with additional
set of thresholds for Hi-Z when converting analog signal to logic -
so I'd have something to work with, even without full support for Hi-
Z throughout the program)?
Since you seem to create the differential signal using an external
tool, maybe you can use the tool to generate another analog channel,
this time indicating the hi-Z state - kind of like a "signal valid"
channel? You could convert that to a logic channel and feed it to your
protocol decoder along with the other signal(s) you need.
Thanks a lot for this - now I'm thinking "How come I didn't think of this
earlier?" :)
Indeed, that is a very viable approach - I will modify my scripts to generate
one extra channel, and then modify the Python decoder to accept one extra logic
input, I feel that should do it!
* Is there a way, to peek into the analog source of a logic signal
(at a given time/samplenum), from inside a PulseView/sigrok Python
decoder?
As of now, libsigrokdecode only supports logic channels, which is why
a conversion is needed for analog channels. This, too, is going to
change... eventually. We're a small team with lots of items on the
wish list, so unfortunately, it takes time.
Again, great to have this explicitly stated - thanks!
Many thanks in advance for any answers!
Thanks for using our software!
And I had forgotten to say earlier - thanks for the great piece of software!
I feel you've done a fantastic job with many hard problems - especially the
(speed) of drawing/plotting of waveforms in PulseView, the fast zoom/unzoom and
the running of the plotting and the decoders in threads; so one can browse a
rendered part of the signal, even if the whole signal is not rendered/decoded
in its entirety yet! I also find the Python protocol decoder architecture very
approachable and natural/understandable. This alone makes me hope I'll end up
with enough time, at a certain point in the future, to make a meaningful
contribution to this project (even if it won't be anytime soon).
Many thanks again,
Cheers!
-Soeren
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
