Digital channel sampling.

[MarkDH102]

As I understand this

Digital channels are PICO board pins D2-D22 and are named accordingly in sigrok. Channels must be enabled (via Pulseview or sigrokcli) starting at D2 and continuously set towards D22

It means if I want to sample at the highest rate, I can only sample D2 to D5 for example? I can't sample D9 to D12. Indeed, pulseview crashes out or will not start, giving an error "Digital channel mask 0x6 not continous". Then subsequent attempts to acquire crash pulseview out and give error "Cannot remove non-existing event source 0xnnnnnnnnnn". And then Notifying user of session error: "generic/unspecified error" Segmentation fault

I am running on a Pi4 1GB RAM Raspberry OS Bullseye 64 bit (up to date). I built sigrok & pulseview from github.

I should add that I'm sampling A2 as well and my sample rate is 500kHz and 5000 samples.

[pico-coder]

MarkDH102, Thanks for the question, and yes I think you understand it mostly correctly. A digital channel mask of 0x6 means that you must have disabled channel D2 and left D3 and D4 enabled. The reason for this limitation on digital samples is to simplify the code that setups the PIO and reduce the amount of channel shifting and masking that was needed by the PICO. So if you enabled D2,D3 and D4 it should work. The analog channels are a bit more flexible because the PICO supports a simple 3:1 mux which makes it easy to get the channels you want. Note that the number of digital channels enabled does not directly effect the maximum sampling rate, (which is up to 120Mhz with no ADC), but it does effect the bandwidth of data going across the link. In cases where the number of requested samples is greater than the storage capacity of the PICO (~200KB) then the sample rate or number of channels needs to be reduced to ensure you stay within about 500KB/sec of data bandwidth on USB. If that is not ensured than the code on the PICO will detect overflow conditions and report an abort. In an abort you will receive some samples that are correct, but not the full expected depth.

At only 5000 samples, the RP2040 will have plenty of internal storage to capture the entire trace even at 21 digital and 3 analog and thus the USB link speed is not a limiter.

I realize it's all a bit confusing. The reason for all of the configurations and modes are trying to support as many use cases as possible, while working around the limitations of the device. Basically for higher sample rates you are limited to the storage capabilities of the device, but for lower sample rates you are limited by the USB link rate. Once your data rate is below the USB link rate than you can capture sample depths up to the limit of what I coded in the pulseview driver (4GB IIRC). I probably need to make some kind of a table to make it clearer...

Let me know if you have any more questions.

[pico-coder]

I added a diagram to the analyzer details, let me know if that helps... https://github.com/pico-coder/sigrok-pico/blob/main/AnalyzerDetails.md

[MarkDH102]

Many thanks for answering my question and going to the trouble of providing the chart. Very helpful. I'd already figured out the Analogue speeds/sample size. I'm finding this whole project of yours very useful. Thanks for spending the time on it. Regarding frequency of sampling. Is it possible to set a fixed list in the dropdown of pulseview? I guess it would mean implementing some messages back to sigrok? I will have a look at your drivers later and see if I can do it myself.

[pico-coder]

From api.c in the sigrok driver here are my comments below. I thought I remembered that it might be possible to specify a list longer than three entries that specified all the unique supported rates, but my memory could be wrong. As my comments say though, I used the any value option for the most flexibility. You do have to make sure you hit enter a time or two after adding the new value to make sure it sticks....

//PulseView reads a sample rate config list as a min, max and step. //If step is 1 then it creates a 1,2,5,10 set of selects, as well as the max. //If step is not 1, then it gives a place to enter any value, which gives the greatest flexibility

static const uint64_t samplerates[] = { SR_HZ(10), SR_MHZ(120), SR_HZ(2), };

[tony1tf]

Hi Shawn

Just downloaded your newest Windows PulseView build. Thanks for the extra work you are doing - I have just been looking at your table of limiting factors. I seem to have slightly different limits. I have tested all 21 dig channels ON at 4Msps with analog off. With 20K samples the code works OK and we get 5ms of data with correct termination and the log shows:

Data stream stops with cbyte 36 char $ rdidx 0 sbytes 0 cnt 60000 pv: Acquisition took 0.30 s

However, with 40K samples at 4Msps which should be OK according to your table, we get an abort and 6144us of data: sr: srgn: Data stream aborts with cbyte 33 char ! rdidx 0 sbytes 0 cnt 73728 sr: srgn: Ending receive on abort sr: srgn: Sending plus to stop device stream sr: session: Stopped. pv: Acquisition took 0.24 s

I am using the uf2 file from the release of Feb 26, which is the newest one AFAIK.

Tony

[MarkDH102]

I'm using a Pulseview build on the Pi4 (8GB 64 bit Pi OS). Feb 26 uf2 file here too. I don't have a 40k sample count in my dropdown. Like you say 20k works ok. I have 50k which aborts with the same error as you. Interestingly, my acquisition times are slightly faster than yours. 0.29 and 0.22

PulseView 0.5.0-git-7e5c839 libsigrok 0.6.0-git-02ded8a/4:0:0 (rt: 0.6.0-git-02ded8a/4:0:0)

[pico-coder]

I just submitted issue #11 which might be causing the effective sample buffers to be a bit shallower than expected. I'll need to run some tests with debug prints from the device to know for sure...

[tony1tf]

Hi Mark

My typo when I wrote 40K instead of 50K. I suspect the acquisition time is related to the age of my PC.

[pico-coder]

acquisition time also depends at what point the device determines that it has overflowed and sends the abort, so it may be dependent on the incoming data pattern and how it effects RLE etc...

Also, I started a new issue to redefine how sample rates work in case you didn't see it:

https://github.com/pico-coder/sigrok-pico/issues/12

[pico-coder]

The rev2 release added run length encoding for digital only samples from 5-21 channels (4 channels and less already had RLE). I also undid the not_in_flash func and increased the malloc for the sample rate ram so we should always get above 200KB for sample memory.