No analog measurements

[lrademacher]

I tried the implementation with PulseView, but i can't get out any analog measurements. Digital seems to work fine (although triggering seems to have a problem as well).

I am measuring at the default 5kHz and using 10k samples. I reduced vertical resolution to 0.01V to see any kind of noise, but there is none regardless if i activate all three analog channels or just one. I also attached a 3V power supply via a 1kOhm resistor to GP26_A0, GP27_A1, GP28_A2, but i see always 0V.

Do you have any hints?

Here is the terminal output:

./pulseview qt5ct: using qt5ct plugin Setting "General_Language" changed to QVariant(QString, "en") Setting "General_Theme" changed to QVariant(int, 0) Setting "General_Style" changed to QVariant(QString, "") Setting "General_SaveWithSetup" changed to QVariant(bool, true) Setting "View_ZoomToFitAfterAcq" changed to QVariant(bool, true) Setting "View_AllowVerticalDragging" changed to QVariant(bool, true) Setting "View_ColoredBG" changed to QVariant(bool, true) Setting "View_ShowSamplingPoints" changed to QVariant(bool, true) Setting "View_FillSignalHighAreas" changed to QVariant(bool, true) Setting "View_DefaultDivHeight" changed to QVariant(int, 48) Setting "View_DefaultLogicHeight" changed to QVariant(int, 32) Setting "View_ShowHoverMarker" changed to QVariant(bool, true) Setting "View_SnapDistance" changed to QVariant(int, 15) Setting "View_CursorShowInterval" changed to QVariant(bool, true) Setting "View_CursorShowFrequency" changed to QVariant(bool, true) Setting "Dec_ExportFormat" changed to QVariant(QString, "%s %d: %r: %1") Setting "Log_BufferSize" changed to QVariant(int, 500) Setting "Log_NotifyOfStacktrace" changed to QVariant(bool, true) Setting "View_FillSignalHighAreaColor" changed to QVariant(uint, 201326592) Setting "View_CursorFillColor" changed to QVariant(uint, 4292667379) srd: AttributeError: Failed to load decoder iec: no 'Decoder' attribute in imported module: module 'iec' has no attribute 'Decoder' srd: AttributeError: Failed to load decoder gpib: no 'Decoder' attribute in imported module: module 'gpib' has no attribute 'Decoder' palette support is disabled sr: srgn: Drain reads sr: srgn: Drain reads done sr: srgn: sr_err level logging enabled sr: srgn: sr_warn level logging enabled sr: std: raspberrypi-pico: std_opts_config_list: sdi/cg != NULL: not handling. sr: std: raspberrypi-pico: std_opts_config_list: sdi/cg != NULL: not handling. sr: std: raspberrypi-pico: std_opts_config_list: sdi/cg != NULL: not handling. sr: std: raspberrypi-pico: std_opts_config_list: sdi/cg != NULL: not handling. sr: std: raspberrypi-pico: std_opts_config_list: sdi/cg != NULL: not handling. sr: std: raspberrypi-pico: std_opts_config_list: sdi/cg != NULL: not handling. sr: std: raspberrypi-pico: std_opts_config_list: sdi/cg != NULL: not handling. sr: std: raspberrypi-pico: std_opts_config_list: sdi/cg != NULL: not handling. sr: std: raspberrypi-pico: std_opts_config_list: sdi/cg != NULL: not handling. sr: srgn: Capture cfg_bits of 0x0 from sample rate 5000 Acquisition took 0.52 s sr: srgn: Capture cfg_bits of 0x0 from sample rate 5000 Acquisition took 2.39 s sr: srgn: Capture cfg_bits of 0x0 from sample rate 5000 Acquisition took 2.39 s sr: srgn: Capture cfg_bits of 0x0 from sample rate 5000 Acquisition took 2.27 s sr: srgn: Capture cfg_bits of 0x0 from sample rate 5000 Acquisition took 2.39 s sr: srgn: Capture cfg_bits of 0x0 from sample rate 5000 Acquisition took 2.39 s sr: srgn: Capture cfg_bits of 0x0 from sample rate 5000 Acquisition took 2.39 s sr: srgn: Capture cfg_bits of 0x0 from sample rate 5000 Acquisition took 2.27 s

[pico-coder]

I was actually using this build today to debug some analog signals and it seemed to work fine, so I don't have any obvious answers. I measured sin waves, square waves etc.

1) With a log verbosity of "-l 5", the driver will print the raw values from the device. Just keep num_samples under 1000 because you'll get lots of print outs. This will show what the device is actually sending and will help confirm whether it's the PICO device or the host.

2) Disable all the digital channels if you haven't already, sometime that perturbs the data pattern enough, though I've never seen analog be completely broken...

3) If the device is sending zeros then we'll need to build some debug builds and see what we can observe. Do you have the ability to monitor the UART TX pin 0? If so all the builds I release send some debug information there which might be helpfull. baud is 115200

4) What platform (CPU/OS) are you building on? I've only been able to test on Raspberry PI, if you have a windows build then post it somewhere and I can try to test it.

5)For the log you posted, I do not get the printouts from "Setting "General_Language" changed to QVariant(QString, "en")" to "srd: AttributeError: Failed to load decoder gpib: no 'Decoder' attribute in imported module: module 'gpib' has no attribute 'Decoder'" I have no idea what those mean, but with a verbosity of 5 it might help show if the driver is sending data but it's being lost on the way to the session/QT.

Shawn

[pico-coder]

I think I've found it and working on a fix, will update with more details later.

[lrademacher]

Great! Nevertheless to give you the full picture here, I performed a measurement on A0 with 100 samples on log verbosity level 5 again and attached the output as log file here: a0_100s.log

[pico-coder]

I have updated libsigrok files to fix this, and also released a few updates to the RP2040 code inlcuding a new uf2 file you should upload. The bug was related to a feature that I have where the rp2040 device can tell the host how to scale a binary value for floating point values. The bug was that a string didn't have a proper null termination and when it was sent to function to split the function would end up returning a bad scale. We then ended up multiplying all of the analog samples by 0. If it doesn't work, run with -l 5 on a short number of samples and I'll have a look.

[lrademacher]

It doesn't seem to have changed anything. Updated Firmware (uf2 file) updates the three files in libsigrok rebuilt libsigrok and installed it rebuilt pulseview (the new libsigrok version is displayed in the about screen)

Here again is the log of a measurement on A0 with 100 samples: a0_100s.log

[pico-coder]

ok, seems to be something about the use of periods vs. commas in how our builds are done. This is the string that the device sends, it says that each bit value is 25.7mV with an offset of 0V. 0.0257,0.0

When I compile libsigrok I get this: sr: [00:00.183135] srgn: A2 scale 0.025700 offset 0.000000 response #0.0257,0.0# but you get: sr: [00:12.176023] srgn: A0 scale 0,000000 offset 0,000000 response #0.0257,0.0# Note that both show the correct string in between the '#', but the resulting scales are different. Since the comma is used as a separator in your output I'm guessing that something is doing a period,comma swap.

I'll either need to just get rid of this feature and make it a fixed scale/offset or find a more universal way to send a floating point number. A quick hack on your side would be to take all this code in protocol.c: if (num_tokens == 2) { devc->a_scale[i]=atof(tokens[0]); devc->a_offset[i]=atof(tokens[1]); sr_dbg("A%d scale %f offset %f response #%s#\n",i,devc->a_scale[i],devc->a_offset[i],response); }else{ sr_err("ERROR:Ascale read c%d got unparseable response %s tokens %d",i,response,num_tokens); //force a legal fixed value. With a scale of 0 we'll always return 1.234 indicating //a failue in parsing the scale devc->a_scale[i]=0.0; devc->a_offset[i]=1.234; }

And replace it with: devc->a_scale[i]=0.0; devc->a_offset[i]=0.0257;

And if it works, that might be the long term fix :).

[pico-coder]

I rewrote the scale and offset to use integer uVolts, updated the libsigrok code and released a new uf2. You should see this in the output now. sr: [00:00.158387] srgn: A0 scale 0.025700 offset 0.000000 response #25700x0# tokens #25700# #0# sr: [00:00.173048] srgn: A1 scale 0.025700 offset 0.000000 response #25700x0# tokens #25700# #0# sr: [00:00.185458] srgn: A2 scale 0.025700 offset 0.000000 response #25700x0# tokens #25700# #0# Also, if for some reason that doesn't parse I modified the failing condition to use an offset of 0 and scale of 25.7mV, but it would be good to know if this new format works for you.

[lrademacher]

This works fine to me now. The problem might have been related to my german localization as we are using commas as decimal separator here... (for completeness: I am using linux mint here)

[pico-coder]

Thanks for helping out here. You mentioned earlier that you might have seen some triggering issues, if so please submit an issue. Thanks again.