1

Apologies in advance if I chose the wrong forum - this is mostly a software question; however, I thought it would be irrelevant to most on StackOverflow that don't do electrical engineering, so I hoped I could get an answer here. If not, please advise a more appropriate place where this question can be moved.

I'm using PulseView (sigrok) on Windows 10 installed via:

I want to analyse multichannel raw analog (binary) data in PulseView. First problem I had, was not knowing how PulseView interprets multi-channel data - interleaved, or not (that is, channel 1 in its entirety, followed by channel 2 in its entirety).

Eventually, I've made this simple test in Python:

import struct

with open('binfile', 'wb') as f:
  for ix in range(256):
    f.write(struct.pack("=B", ix))

Then, I imported this via Open icon in PulseView/"Import Raw analog data without header..." (remember to set the file filter to "All files", otherwise binfile will not be listed, as only .raw or .bin file extensions are shown by default), and used:

  • Data format: U8 (8-bit unsigned int)
  • Number of analog channels: 10
  • Sample rate (Hz): 0

This imports, and gives this plot (after manually setting all "Vertical Resolution" to 1V/DIV, accessed when you left-click the CH1 etc labels which sit at the left of the tracks):

binfile-pulseview

As it can be seen, when the cursor is over the leftmost sample in the multitrack, the values we get are: -500 mV, -496 mV, -492 mV, -488 mV, -484 mV, -480 mV, -476 mV -- which for me, means that PulseView interpreted the data in binfile, to be interleaved, as in:

byte1|byte2|byte3|...|byte10|byt11|byt12|byt13|.....
  ==
ch1s1|ch2s1|ch3s1|...|ch10s1|ch1s2|ch2s2|ch3s2|.....

So that question is solved (hopefully, unless I interpreted it wrongly)

What I still don't get, is:

  • Why did PulseView decide to map byte value 0x00 to -500 mV, and byte value 0xFF to 500 mV? In other words, how did it decide on this default range - is this documented anywhere, and can I change the interpreted analog range (in volts)?
  • 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).
sdbbs
  • 125
  • 3
  • 1
    Welcome. Without an expert in PulseView to offer help, we may not be able to help you. Strictly speaking, this is a software issue, not a electronic design issue. –  Mar 08 '19 at 17:11

1 Answers1

0

Well, I managed to get answers to these questions, courtesy of the sigrok-devel mailing list:

  • Why did PulseView decide to map byte value 0x00 to -500 mV, and byte value 0xFF to 500 mV? In other words, how did it decide on this default range - is this documented anywhere, and can I change the interpreted analog range (in volts)?

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

And for the second question:

  • 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 OP, I captured it on this image in OP ... 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):

binfile-pulseview-0.5.0-git-58cd5b5

So that solves this issue for me now - thanks a lot to sigrok-devel again!

sdbbs
  • 125
  • 3