Testing latest Windows version of Pulseview

[tony1tf]

Latest version in your Dropbox is not yet visible - only get message about the deleted old one.

[pico-coder]

Sorry, NOOB dropbox mistake. When you create a link to the file it is no longer good if you delete it and then copy over a same named file. New link is in the Readme.md of the Pulseview directory.

[tony1tf]

Your latest code isn't working - I tried mode and putty, but no difference. I got a lot of error messages:

sr: asix-omega-rtm-cli: Cannot execute RTM CLI process: Failed to execute helper program (Invalid argument) sr: srgn: Drain reads sr: srgn: Drain reads done serial-libsp: Read error (995): The I/O operation has been aborted because of either a thread exit or an application request.. serial-libsp: Read error (22): The device does not recognize the command.. serial-libsp: Read error (22): The device does not recognize the command.. serial-libsp: Read error (22): The device does not recognize the command.. serial-libsp: Read error (22): The device does not recognize the command.. srgn: ERROR:Serial_w_resp failed (-2). sr: srgn: 1st identify failed serial-libsp: Error opening port (2): The system cannot find the file specified.. sr: srgn: 2st serial open fail sr: srgn: Drain reads sr: srgn: Drain reads done srgn: ERROR:Serial_w_resp failed (0). sr: srgn: 1st identify failed sr: srgn: Send second * srgn: ERROR:Serial_w_resp failed (0). sr: srgn: Second attempt failed serial-libsp: Error opening port (5): Access is denied.. sr: srgn: 1st serial open fail serial-libsp: Error opening port (5): Access is denied.. sr: srgn: 1st serial open fail sr: srgn: Drain reads sr: srgn: Drain reads done srgn: ERROR:Serial_w_resp failed (0). sr: srgn: 1st identify failed sr: srgn: Send second * srgn: ERROR:Serial_w_resp failed (0). sr: srgn: Second attempt failed

[tony1tf]

A second run in administrator mode, looks like it succeeded in communicating with the Pico, but still failed to connect to the device. Errors attached as file. errors.txt

[pico-coder]

somehow I must have copied the wrong build over. From your errors .txt you don't have the new serial parameters I specified... You have: sr: serial: Parsing parameters from "57600/8n1". sr: serial: Got params: rate 57600, frame 8/0/1, flow 0, rts -1, dtr -1.

But it should show: sr: serial: Parsing parameters from "115200/8n1/dtr=1/rts=0/flow=0". sr: serial: Got params: rate 115200, frame 8/0/1, flow 0, rts 0, dtr 1.

I'd swear I copied the same file I installed on my machine to dropbox....

[tony1tf]

I'll make sure I installed the right one - I'll start again.

[pico-coder]

So I uninstalled my pulseview, downloaded from dropbox, and it works fine. However, one thing that is very weird is that I think I only dropped one update yesterday and your logs have print outs indicating you have some changes I made yesterday, but not all of them. I'm going to do another build and post it, but you might try finding all the C:\ProgramFiles(x86)\sirgrok files and deleting them... But I'll admit, it doesn't feel like its making sense....

[pico-coder]

I did a new build, and added a "rev1" to the name of the file. https://www.dropbox.com/s/rnktz830phgl1ag/pulseview-0.5.0-git-7e5c839-installer_rev1.exe?dl=0

Here's a snip of the log at debug level 5 sr: srgn: Opening COM7. sr: serial: Opening serial port 'COM7' (flags 1). sr: serial: Parsing parameters from "115200/8n1/dtr=1/rts=0/flow=0". sr: serial: Got params: rate 115200, frame 8/0/1, flow 0, rts 0, dtr 1. sr: serial: Setting serial parameters on port COM7. sr: serial: DBG: serial_set_params() rate 115200, 8n1 sr: serial: Flushing serial port COM7. sr: srgn: Resetting device with *s at COM7.

[tony1tf]

I ran without going to admin mode, and the Pico got discovered immediately. However, PulseView locked up on acquisition at 5MHz. Crashed, so I couldn't see the error log. Second run - didn't do anything different and it worked! I saved the logfile after completing acquisition - looking good logfile.txt .

[pico-coder]

ok. based on your logs you left all channels enabled including ADC, and 5Mhz is well above what the pico can suport. You should see the driver force the sample rate (via the log output) to 166khz. Also, when you crank up the verbosity that fundamentally changes the usb data transfer rates because the host ends up spending so much time on printfs. So you can possibly have "Heisenberg" issues where things get better or worse depending on verbosity, but overall I've never had pulseview crash on windows yet...

I did leave all channels enabled and sample rate to 5Mhz, debug level 2, and saw no issues at 1k samples and 500k samples, but the driver did print the warning about the reduced sample rate.

[tony1tf]

I've just had a few more goes at 5MHz and all channels, and PulseView crashed every time before I could save the log which was at level 5. I'll try at level 2.

[tony1tf]

I give up for now - it kept crashing and finally I had to use the task manager to kill it. It was even locking up on the initial searching for drivers.

[pico-coder]

:(. The initial search doesn't even try to access the serial port, nor does it access the new driver code I wrote.
Best I can think of is to uninstall and then fully delete the C:\ProgramFiles(x86)\sigrok director, reinstall, and reboot....

[tony1tf]

I tried uninstalling and reinstalling. It finds the Pico every time, now, but crashes when acquiring. This is behaviour I have seen with the Cypress FX2 clone as well. It doesn't seem to acquire, then you press run again and the program locks up. There seems to be a lack of timeouts in PulseView, so you can't easily escape. I will be using PulseView with the FX2 tomorrow at the National Museum of Computing, so I hope I havn't damaged my saved older version. It looks OK with my recorded files, so I hope it is OK with real hardware. Need bed now for an early start.

[pico-coder]

Pulseview doesn't have any timeouts at all, and really I don't think it should because it has no idea when a device may send returning samples or not based on internal triggering etc.

It does however support a stop feature - if you press run and the driver hasn't completed the acquisition you get a stop button which communicates with the driver to stop acquiring. I just tried that now and it works fine.

Sounds like you might have some kind of serial driver issue, maybe you need to rollback/update? I'm on Win 10 and the PICO shows up as a USB Serial Device. The driver version is 10.0.19041.1 from Jun 21,2006.

[pico-coder]

BTW, what Windows version are you running?

[tony1tf]

The Pico shows up as a serial device 'Board CDC (Interface 0) (COM5)' Driver provider libwdi, 13/3/2022, vers 1.0.0.0 File C:\WINDOWS\system32\DRIVERS\usbser.sys Microsoft Corporation 10.0.19041.1202 (Winbuild.160101.0800) So that looks like a similar driver to yours, but much more recent.

The Pico also shows up as a 'Reset' device under USB Devices with 3 driver files: C:\WINDOWS\system32\DRIVERS\winusb.sys C:\WINDOWS\system32\WdfCoInstaller01011.dll C:\WINDOWS\system32\DRIVERS\WinUSBCoInstaller2.dll

Computer is running Windows 10 Home, vers 21H2, Installed 29/10/2020, OS Build 19044.1586

As I said in my comments previously, I have always had problems with PulseView in that sometimes it will lock up with the Cypress FX2USB board using fx2law firmware, and a different driver - I have to get to TNMOC to see which one when I plug in the board. In the earlier days of using that, I would have to re-enter all the labels for the individual channels, but now I am able to use the setup files - I should have discovered them earlier - they may have always been there.

Tony

On Mon, 14 Mar 2022 at 22:39, pico-coder @.***> wrote:

BTW, what Windows version are you running?

— Reply to this email directly, view it on GitHub https://github.com/pico-coder/sigrok-pico/issues/7#issuecomment-1067371660, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJKGTVJVBBPUXKGEIIS5ZDU7653PANCNFSM5QU5IQ7Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you authored the thread.Message ID: @.***>

[tony1tf]

More test results. Using the 'pop-out' pulseview log, I could copy and paste to a separate edit window in case it crashed. I left the sample at 1K and all channels enabled and increased acquisition rates from 500Hz to 50MHz,one '0' at a time. I note that it takes 2 acquisitions to get the new rate, but it didn't crash. So this might be because it was a small sample. Logfile attached.

On Tue, 15 Mar 2022 at 06:16, Tony Abbey @.***> wrote:

The Pico shows up as a serial device 'Board CDC (Interface 0) (COM5)' Driver provider libwdi, 13/3/2022, vers 1.0.0.0 File C:\WINDOWS\system32\DRIVERS\usbser.sys Microsoft Corporation 10.0.19041.1202 (Winbuild.160101.0800) So that looks like a similar driver to yours, but much more recent.

The Pico also shows up as a 'Reset' device under USB Devices with 3 driver files: C:\WINDOWS\system32\DRIVERS\winusb.sys C:\WINDOWS\system32\WdfCoInstaller01011.dll C:\WINDOWS\system32\DRIVERS\WinUSBCoInstaller2.dll

Computer is running Windows 10 Home, vers 21H2, Installed 29/10/2020, OS Build 19044.1586

As I said in my comments previously, I have always had problems with PulseView in that sometimes it will lock up with the Cypress FX2USB board using fx2law firmware, and a different driver - I have to get to TNMOC to see which one when I plug in the board. In the earlier days of using that, I would have to re-enter all the labels for the individual channels, but now I am able to use the setup files - I should have discovered them earlier - they may have always been there.

Tony

On Mon, 14 Mar 2022 at 22:39, pico-coder @.***> wrote:

BTW, what Windows version are you running?

— Reply to this email directly, view it on GitHub https://github.com/pico-coder/sigrok-pico/issues/7#issuecomment-1067371660, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJKGTVJVBBPUXKGEIIS5ZDU7653PANCNFSM5QU5IQ7Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you authored the thread.Message ID: @.***>

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 device cfg_bits of 0x0 from sample rate 5000 pv: Acquisition took 0.84 s sr: srgn: Capture device cfg_bits of 0x0 from sample rate 5000 pv: Acquisition took 0.85 s sr: srgn: Capture device cfg_bits of 0x0 from sample rate 50000 sr: srgn: Dropping 1 device bytes pv: Acquisition took 0.40 s sr: srgn: Capture device cfg_bits of 0x0 from sample rate 50000 pv: Acquisition took 0.28 s sr: srgn: Capture device cfg_bits of 0x0 from sample rate 500000 srgn: ERROR:3 channel ADC sample rate dropped to 166.660khz sr: srgn: WARN: Forcing common integer divisor sample rate of 160000 div 150 pv: Acquisition took 0.26 s sr: srgn: Capture device cfg_bits of 0x0 from sample rate 160000 pv: Acquisition took 0.24 s sr: srgn: Capture device cfg_bits of 0x0 from sample rate 5000000 srgn: ERROR:3 channel ADC sample rate dropped to 166.660khz sr: srgn: WARN: Forcing common integer divisor sample rate of 160000 div 150 pv: Acquisition took 0.26 s sr: srgn: Capture device cfg_bits of 0x0 from sample rate 160000 pv: Acquisition took 0.24 s sr: srgn: Capture device cfg_bits of 0x0 from sample rate 50000000 srgn: ERROR:3 channel ADC sample rate dropped to 166.660khz sr: srgn: WARN: Forcing common integer divisor sample rate of 160000 div 150 pv: Acquisition took 0.26 s

[tony1tf]

Increasing to 100K samples at 5MHz, I see that the rate changes on its own to 160000Hz. I also get an abort message, but no crashes! I need to get long sample runs up to 1M at 4MHz for the work I am doing. Are you limiting the length for some reason?

sr: srgn: Capture device cfg_bits of 0x0 from sample rate 160000 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 pv: Acquisition took 0.32 s sr: srgn: Capture device cfg_bits of 0x0 from sample rate 160000 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 pv: Acquisition took 0.32 s

[tony1tf]

I stopped the analog execution and just left the 21 digital inputs. That stops the reduction of rate and it appears to acquire OK, although the inputs are floating at the moment. Howver at 10k samples it is OK, but at 20K samples or above it shows an abort which terminates the acquisition early:

sr: srgn: Capture device cfg_bits of 0x0 from sample rate 5000000 pv: Acquisition took 0.30 s sr: srgn: Capture device cfg_bits of 0x0 from sample rate 5000000 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 pv: Acquisition took 0.24 s

[pico-coder]

Make sure you only enable the digital channels that you need. You will see substantial increases in the ability to sample higher sample rates as you reduce the enabled channels, specifically you will see gains at 4, 7 and 14 channels.
4 channels enables run length encoding which is your only hope for reaching 5Msps streaming rates at 1M samples. The PICO only has 200kB of storage RAM so the only way for your case to work is to stream across USB. Even then it will only work if what you are sampling has low activity factors so that run length encoding can have an effect. On my windows box I've gotten an effect USB bandwidth of 4.8Mbit/sec. At 1 byte per sample that means you can get more than 600k samples per second unless you use run length encoding to compress the data stream. With low activity factor signals I've reached 15-20Msps, but I have no idea what you are trying to capture.

Data stream aborts which end with an exclamation "!" indicate that the PICO device has encountered an overflow condition. Basically it was unable to send all of the requested samples across USB for a given chunk of samples before the DMA engine indicated it finished the next sample. 20k samples at 21 channels is starting to approach the point where the PICO might not be able to fully capture the sample internally.

[pico-coder]

BTW, other run length encoding schemes might be possible, i.e. doing encoding across more than just 4 bits. My assumption was that most "higher" speed interfaces were also narrow (I2C,narrow I2S, RS232 etc), and that wider were slower (wide I2S -such as a 44ksps DAC). That obviously isn't always a correct assumption, but at some point you have to accept the limitations of usb1.1 interface and accept that you won't be able to stream everything.

[tony1tf]

Hi Pico-Coder

I was under the impression that the Pico is a much more capable device than the FX2 USB device I have been using for the last 3 years. The FX2 does 4 or 8MHz and 1 million samples without a problem. For EDSAC at TNMOC I was looking forward to the 20 channels from the Pico plus the lower speed ADC inputs. EDSAC uses a 500kHz clock, so 4MHz gives me 4 samples per half cycle which means I get pretty accurate waveforms. Perhaps we need a faster way of getting the data into PulseView, otherwise this won't be of any use to me.

cheers Tony

On Tue, 15 Mar 2022 at 16:24, pico-coder @.***> wrote:

BTW, other run length encoding schemes might be possible, i.e. doing encoding across more than just 4 bits. My assumption was that most "higher" speed interfaces were also narrow (I2C,narrow I2S, RS232 etc), and that wider were slower (wide I2S -such as a 44ksps DAC). That obviously isn't always a correct assumption, but at some point you have to accept the limitations of usb1.1 interface and accept that you won't be able to stream everything.

— Reply to this email directly, view it on GitHub https://github.com/pico-coder/sigrok-pico/issues/7#issuecomment-1068188739, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJKGTSQJFA35VTOX542W4LVAC2U7ANCNFSM5QU5IQ7Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you authored the thread.Message ID: @.***>

[pico-coder]

Well, I didn't want to get into too many special cases, but if I can say it was used on EDSAC maybe I'm in.... :) Since you need to measure a free running clock, run length encoding won't help directly unless we do something else. We(I) could create a mode in the PICO where it only sent a sample across the wire on the falling (or rising) edge of digital input D2 which was connected to the clock. Thus we should get very accurate waveforms when the signals are stable. We'd still sample at 2-4Mhz, but only send 500k samples per second down the wire.

But, if you want stream we need to stick with the 500-600kByte limitations of usb1.1. That means you could only sample up to 7 digital signals to fit into the 1 byte. Or we would need to figure out some kind of way to do run length encoding i.e. if you knew certain signals were stable over long periods.

If that seems at all interesting, you might grab a sample trace of the waves you are looking at and post them here.

Another alternative might be to define some kind of more advanced hardware triggering modes. Do you really need 5 million samples, or is that how often something interesting happens?

Note that combining with analog might present it's own challenges. I currently require the ADC and digital pins to sample at the same clock for the sake of keeping the DMA buffer handling simple, and the ADC can't go above 500Khz on a single channel. Do you still need to 5 million samples with ADC at 500ksps? Maybe we should figure out the digital only problem first.....

[tony1tf]

Hi @pico-coder

Thanks for your thoughts. I always have an EDSAC clock track which is just over 500kHz. EDSAC generates various serial signals that are 18 or 36 bits long with 2 microsecond bit time - ie at the clock rate. I was hoping that the ADC could do some sub sampling so that in one capture we can get analogue representation of any 3 channels, but just having more digital channels than the 16 we currently have would also be useful. We have written an EDSAC decoder which allows the serial data values to be displayed. I will attach the edsac decoder Python files that go into a directory called 'edsac' in share/libsigrokdecoder/decoders, along with a short capture from yesterday using my Cypress FX2 clone. I have had to edit the decoder because the latest PulseView app needs slightly different functions, compared with older versions. Note - I had to add .txt to the files to get them accepted by the upload code.

Tony

init.py.txt pd.py.txt

20220315_XXX_1.sr.txt 20220315_XXX_1.pvs.txt

[pico-coder]

Took a look at the waves. I noticed that some signals like "COUNTER" are actually narrower then half a clock pulse, and thus a sample at either the rising edge or the falling edge of "CLK" would miss it. (For example at time 198.2us to 199.2us COUNTER is high completely inside of a high pulse of CLK. That leads me to think that COUNTER isn't synchronous to CLK, or maybe has some very strange clocking. Regardless, a rising/falling sample paradigm won't work.

There are spots here and there all non CLK signals are the same value for many clock periods, and thus if CLK wasn't sampled a run length encoding might get to a 2x or 3x run length encoding. That might allow full streaming at 21 channels. But it's admittedly very close, and it kind of depends on how badly clock is really needed...

As for analog, I don't think doing more than 1 ADC channel will be useful. At 500ksps you really are undersampled, and since the 3 ADC channels use 1 ADC converter each of the samples will be separated 2us apart. Pulseview doesn't really allow a way to show that skew between the samples as it shows all samples lined up in time even if they aren't. Thus with 3 ADC channels you end up with a 167Ksps per channel with up to a 4us skew between the ADC sample and the digital sample. And since there is no good way to encode/RLE analog samples you won't be able to stream them continuously.

[tony1tf]

Hi

These waveforms come from valve electronics with analogue signals through multiple stages, inverters, buffers, diode AND and OR gates, delay line etc. It is a nightmare to get everything changing phase at the right time, even though they are all derived from the one master clock. Hence the problems you are seeing. I use a 4 channel scope as well to understand the signals, but the logic analyser points me to which signals to look at when we have problems, which is most of the time!

Tony

On Wed, 16 Mar 2022, 16:09 pico-coder, @.***> wrote:

Took a look at the waves. I noticed that some signals like "COUNTER" are actually narrower then half a clock pulse, and thus a sample at either the rising edge or the falling edge of "CLK" would miss it. (For example at time 198.2us to 199.2us COUNTER is high completely inside of a high pulse of CLK. That leads me to think that COUNTER isn't synchronous to CLK, or maybe has some very strange clocking. Regardless, a rising/falling sample paradigm won't work.

There are spots here and there all non CLK signals are the same value for many clock periods, and thus if CLK wasn't sampled a run length encoding might get to a 2x or 3x run length encoding. That might allow full streaming at 21 channels. But it's admittedly very close, and it kind of depends on how badly clock is really needed...

As for analog, I don't think doing more than 1 ADC channel will be useful. At 500ksps you really are undersampled, and since the 3 ADC channels use 1 ADC converter each of the samples will be separated 2us apart. Pulseview doesn't really allow a way to show that skew between the samples as it shows all samples lined up in time even if they aren't. Thus with 3 ADC channels you end up with a 167Ksps per channel with up to a 4us skew between the ADC sample and the digital sample. And since there is no good way to encode/RLE analog samples you won't be able to stream them continuously.

— Reply to this email directly, view it on GitHub https://github.com/pico-coder/sigrok-pico/issues/7#issuecomment-1069301469, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJKGTRUS6AEW76LXBA66ZDVAIBVPANCNFSM5QU5IQ7Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you authored the thread.Message ID: @.***>

[pico-coder]

I took at look at those waveforms and at the 4Msps rate there is a 13% activity factor (13% of the samples are a value change). Thus we could get down to 520k samples sent per second along with an RLE encoding. But, at 3 bytes per samples we'd reach 1.5Mbytes per second which is above the USB link bandwidth (around 600kB/sec). So I don't think we'll be able to stream a constant set of samples above 7 or so channels, and you already have that with your other analyzer.

It looks like the trace you posted was sufficient to cover a full pattern sequence, but there's probably more complexity to it than I realize. Don't forget to disable as many channels as possible to maximize trace sample depth (4,8, 16 and 21 channels are the thresholds).

As for analog, you should be able to stream one to three analog channel only at usb rate. Adding any digital channels will go above the link and you'll be stuck with depths equal to the depth of the trace ram of the PICO.

If you have any special triggers we might see if we can come up with a hardware based trigger to allow you to capture a useful trace that fits in the storage RAM.

[tony1tf]

Hi

That particular run stopped prematurely after execution of 10 instructions, due to a problem with a coupling capacitor. We often have to collect long runs to find an error. I can also use a hardware trigger - when an error condition comes up - to freeze the acquisition, relying on pre-trigger to find what caused the error.

Tony

On Wed, 16 Mar 2022 at 20:18, pico-coder @.***> wrote:

I took at look at those waveforms and at the 4Msps rate there is a 13% activity factor (13% of the samples are a value change). Thus we could get down to 520k samples sent per second along with an RLE encoding. But, at 3 bytes per samples we'd reach 1.5Mbytes per second which is above the USB link bandwidth (around 600kB/sec). So I don't think we'll be able to stream a constant set of samples above 7 or so channels, and you already have that with your other analyzer.

It looks like the trace you posted was sufficient to cover a full pattern sequence, but there's probably more complexity to it than I realize. Don't forget to disable as many channels as possible to maximize trace sample depth (4,8, 16 and 21 channels are the thresholds).

As for analog, you should be able to stream one to three analog channel only at usb rate. Adding any digital channels will go above the link and you'll be stuck with depths equal to the depth of the trace ram of the PICO.

If you have any special triggers we might see if we can come up with a hardware based trigger to allow you to capture a useful trace that fits in the storage RAM.

— Reply to this email directly, view it on GitHub https://github.com/pico-coder/sigrok-pico/issues/7#issuecomment-1069583703, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJKGTWYQQD75FGAG73CCQDVAI6X5ANCNFSM5QU5IQ7Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you authored the thread.Message ID: @.***>

[pico-coder]

So for your current triggering do you use the triggers specified via pulseview (i.e. right click the channel and pick rising/falling/level etc?). I'm not familiar with the FX2 to know whether it does HW or SW based triggering. Being that it's wire rate is much faster I don't think you'd know the difference for the FX2.

I currently only support that on the pulseview SW side of things but could push the triggers and precapture ratio into the PICO.
Assuming we had a similar triggering in HW and only supported ~70k samples of 21 channels around the trigger would that be useful? i.e. is that then enough trace depth?

[tony1tf]

Hi I believe the fx2 is using a hardware trigger. Yes - I set it up to trigger off a channel as you describe, then an led flashes on the fx2 until the trigger happens. I usually set a few % pretrigger.

[pico-coder]

So I'm thinking towards having hardware triggering being something fully specified within the pico which would require a recompile of the PICO code. The reasoning is that it would allow more complicated triggering and allow for the SW based triggering to be left alone. There might also be confusion between the two in how they implement triggers (i.e. are all triggers on the same sample or across multiple ones). The downside is that the user (tony) has to setup builds for the pico, but you sound like the kind of user that would go for that.

For starters I think we'd have something similar to pulseview. In C, you'd just have 5 21 bit mask fields indicating which channels would be level0,level1,rising,falling or changing. When you hit all the conditions you'd be triggered, and would send out a set of previous samples from a ring buffer. We do need to keep it simple as at 4Mhz we have only 31 core clocks per sample to push data to the ring buffer, and do the trigger checks.

Thinking as I type it might not be that bad to use the same trigger settings as pulseview. One of those things you have to try to see how it goes...

[tony1tf]

I started replying but GitHub decided to ignore me, so try again. I have seen your postings on the R Pi forum as well, and have requested further help there. I was wondering if a faster interface than USB on the Pico could be used, or even some sigrok processing on the Pico, but I guess your ideas for cutting down the data rate are best. I like the idea of triggers and buffering, but it wouldn't be the flexible tool I get with the FX2.

[veloyage]

Hi there. Interesting project, would love to use it for a university lab course (next week) where we have Picos (well, Adafruit Qt Py 2040s) anyway. The windows build dropbox link seems to be broken again, could you have a look? I can rebuild the MCU code to fit, but the Pulseview build sounds complicated, so it would be great to have a working download. Best, Thomas

[pico-coder]

Link fixed, let me know how it goes. https://github.com/pico-coder/sigrok-pico/blob/main/pulseview/Readme.md

BTW, @tony1tf , I haven't forgotten about hw based triggering and am in the process of adding it, but not done yet.

[veloyage]

Great, thank you, download works. Device and Pulseview seem to work well with the windows build and the provided uf2, I can connect and sample up to the limits of the device. Tried USB and UART, will do I2C in the next days. I2C should be fine, USB works but is not great with the limitations in speed and capture length - but thats ok :) I did not test more than 2 channels, triggering and analog too much, but as it is, it will work well for the students. Maybe two things: 1) if I unplug the device and then try to capture in pulseview, it freezes, would be nicer if it would give an error after a short timeout. 2) the sample rate selection in single Hz is a bit tedious, would be good to have a list similar to the one for the demo device with kHz and MHz.

[veloyage]

Ah, hardware wise I tested with an adafruit feather with the stemma connector clips they sell, may use it with the QT Py too. Only two easily usable channels, but small, cheap and convenient.

[pico-coder]

Please make sure that you disable all unused channels in Pulseview as doing so will increase storage for the remaining channels. There is nothing I can do about the serial unplug problem, as there are too many software layers below my driver that get unhappy with unexpected disconnects. So any time you plug or unplug you should at least restart the session in Pulseview if not the entire app. As for the sample rate, it's the only way that I can get the flexibility in the sample rates. You can just type in the frequency directly and make sure you hit enter to ensure the change gets applied. I'll agree it's a bit clunky that it doesn't seem to accept the value update, but like the serial port stuff it's out of my control.

[veloyage]

First of all, I don't want to complain, I am happy this project exists :) 120 MHz (thanks to the PIO) is kind of a lot for a $1 MCU, and I was too lazy to program something similar myself. And none of the other projects I found worked.

I did disable all but two channels immediately and now saved a config so I dont have to manually do it every time. The performance is good, the hardware limitations are clear and it's cool that USB decoding kind of works. I also have to say I am not sure if the many errors it decodes are an issue with the sampling, the decoder or simply insufficient length to properly decode the higher layers of the protocol.

About the disconnects: I thought the disconnect handling might be part of your driver. Not really an issue.

Frequency selection: I just wish it would accept SI prefixes :). And for me, a fixed list like for the demo device (3 values per decade between 1 Hz and 120 MHz) would work well. Is this actually on the pulseview side or communicated from the Pico?

[tony1tf]

I have been testing the SW trigger, but I am regularly getting an abort before the signal triggers. And its a bizarre wrong acquisition time.

sr: srgn: Capture device cfg_bits of 0x0 from sample rate 500000 sr: srgn: Entering sw triggered mode sr: srgn: Data stream aborts with cbyte 33 char ! rdidx 0 sbytes 7376 cnt 192560 sr: srgn: Ending receive on abort sr: srgn: Sending plus to stop device stream sr: session: Stopped. pv: Acquisition took 87.39 s

[tony1tf]

I am also having problems with the X scale not showing the correct timing. For instance, 20ms shows as 200ms, even though the 'Total Sampling Time' is correct on the tooltip over the frequency box.

[pico-coder]

Aborts are never going to look pretty because they are an indication from the PICO that it wasn't able to send the sample data out of a DMA buffer before the PIO/ADC needed to write that buffer for the next set of samples.

I haven't noticed the 10x factor issue, but likely its an artifact of the abort - i.e. something in PV assumed you would see the full set of samples but you only got a fraction due to the abort .

SW triggers by nature require a continuous sampling mode and thus require that your data bandwidth on USB be <=~500KB/sec. Assuming you are still doing your 4Msps on 16 or so channels you are well above that rate. I don't know how PV calculates acquisition time, but again, with aborts all calculations should be suspect (but you are least assured that the samples you got are correct).

BTW, I was playing around with doing triggers on the PICO and I don't think it will be possible to support to HW triggering at the sample rates you need. Too many calculations are needed to perform the triggers, move data from the DMA buffers to either a ring sample buffer(for pretrigger support) or to a usb send buffer, and other various functions to the extent that you can't perform the trigger with continuous sampling.

Also, thanks for the note on the hackaday link, guess I won't have to prep a press-release :).

[tony1tf]

Here's an example where the sw trigger behaved, but showed the wrong time scale - should have been 50ms .

[tony1tf]

At 10 Msps it will do 4 channels but not 5 as you can see in the log .

[pico-coder]

@tony1tf , if you look at the reported sample rate in the first run you'll see that it is down at 100K rather than the 10Mhz, so it's the usual problem of the the sample rate not updating because you didn't hit enter enough etc.. Hopefully the fix for issue #12 will take care of that.

Your 2nd run did actually run at 10Mhz. And yes, with 4 or fewer channels you get the "D4" optimized mode which does RLE and can fit either a 4 channel sample and a 3 bit RLE repeat value OR an encoded repeat value in each byte. The D4 mode supports RLE encodings up to 640x so low duty cycles can stream across USB.

[pico-coder]

Tony, I just released Rev2 update for both sigrok and the PICO device. Windows driver is available on drop box, you will also need a new uf2 file, both in their usual places. Will post more details in the morning, but this adds run length encoding for digital only modes of 5-22 channels, also adds a sample rate pull down and other changes.

[pico-coder]

oh, make sure you save your current uf2 if you haven't already, it is possible to get an old version from github, but in case something goes wrong you need to be able to revert to rev1.

[pico-coder]

With rev2 released we now have "SI" prefixes in the drop down. Aborts will always be, well, aborts. While the rp2040 is an amazing device there will be cases where the devices capture depth isn't quite enough and the USB rate might just be quite enough where it's worth the risk to see if streaming is capable, so it's the best solution I could come up with. Since this issue refers to stuff previous to rev2 it really isn't the latest version so closing out.

[tony1tf]

Will do, thanks! Tony

On Wed, 13 Apr 2022, 05:51 pico-coder, @.***> wrote:

oh, make sure you save your current uf2 if you haven't already, it is possible to get an old version from github, but in case something goes wrong you need to be able to revert to rev1.

— Reply to this email directly, view it on GitHub https://github.com/pico-coder/sigrok-pico/issues/7#issuecomment-1097554524, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJKGTQJ5DJQ5SUIQ23TDGLVEZHGNANCNFSM5QU5IQ7Q . You are receiving this because you were mentioned.Message ID: @.***>