Improving the number of samples possible?

[RudolphRiedel]

I found this interesting and did not consider every aspect of it untill now.

I built my own board, because I could and I did not build a Pi-Pico board before:

I designed this board and ordered it a couple of days ago from JLCPCB.
Apart from the 1x9 2.54mm pin header, everything will be populated by JLCPCB.

The board is rather small at 44mm x 28mm.
I went with USB-C, just because I never used that in one of my designs.
I reduced the number of channels to 8 as I mostly look at SPI and need 2 pins extra, so 6 in total.
I am using 74LVC2G17 as input buffers as these are 5V tolerant with 3.3V supply, so the input range is about 2.5V to 5.5V.
The part actually placed by JLCPCB is C3294723 ([AIP74LVC2G17GB236.TR)
The I/Os used are 0...7, I maybe should have used 2...9.
I added a reset button since I really dislike the press-button-insert-cable approach that the original Pi-Pico as pushing.
The coil I went with for the core supply is the one Adafruit is using, so it should be working.
I could not do much in regards of length matching the input lines, but the range is from 11.034mm/60.481ps to 6.978mm/38.247ps between the controller and the 51R series resistors I am using.

Anyways, I started to play with the 6.5 beta software.
I got it to compile and added my own board definition.
I am running the software on a Waveshare RP2350-Zero and did not attach anything to it, yet.
I noticed that with limited channels, no complex-trigger pins and GPIO_LED, the size of the .UF2 dropped from 90kiB to 77kiB,
So I increased the CAPTURE_BUFFER_SIZE untill I get an error message, the limit is 469kiB which results in 480.256 maximum samples showing up in LogicAnalyzer 6.5 software.
Ok, nice upgrade.

Then it hit me, this is not even 10ms with the 50MHz I was using -> this is practically unuseable for me.

What could be done about this?
A PSRAM could be added, but if that actually could be made to work, that would only extent the samples to 170ms @50MHz.
And it probably would not even work, since at best write speed to the external SRAM is less than 50MB/s.
So at best this would improve the number of samples with frequences below maybe 40MHz, mabye even less than that.

What about compressing the buffer then?
As this is a byte stream, the good old RLE (Run Length Encoding) could be used to compress the buffer in realtime.
Sampling then does not end at a fixed sample-number, but when the buffer is full.
This needs two special tokens, for example 0xff for a new value found, 0xfe for the value 0xff found.
0xff would be followed by the byte value and the number of consecutive bytes with that value.
Example:
0xff 0x00 0xfd 0xff 0x01 0x30 0xff 0x03 0x30
-> 349 samples in 9 bytes of lossless compression

[gusmanb]

Not possible. Consider this:

If you want to capture at 50Mhz even if you run at 400Mhz the RP2350 you have 8 cycles to implement the encoding, you need in those 8 cycles to pull from the PIO fifo, compare the values, check if needs escape if it is a different value, check how many bits are you capturing, check if you need to roll because is a ring buffer, store to memory one to three bytes, increment counters, check if the buffer is full, etc, and all done using only the CPU, so that's already nearly impossible if not impossible.

Also, you are using only 8 channels so I assume you are analyzing something like SPI or I2C, if you have so many "repetitive" samples that RLE is useful, then what you should use is the burst mode, let's supose that you are analyzing SPI, then if you use the burst mode, set the trigger to capture when CS is low, and set a small window size you will skip all the "silences" optimizing the usage and only retrieving data when there is really meaningful data achieving basically the same as if you were using RLE. In fact many times it will give you more capacity than RLE as with RLE depending on the data it will use even more space than unencoded when it is mostly all different values.

[RudolphRiedel]

The window is way too small to help me with my application, even with burst-mode - of which I had to read-up what it actually does.
Going lower than 50Msamples/s also is not really a viable option for me as that would result in loss of information.
That sure is a me-problem and it is a hardware limitation that can not be fixed.

Well, in about two weeks I should be receiving the boards and then can play with them,
this should still work fine in applications using SPI transfers with only a couple of bytes.
And of course with other things like I2C.

If it works like expected, I will be releasing all the board files.

So, I guess what this actually does is write the data to SRAM using the PIOs?
Writing pages of SRAM to PSRAM should be even slower than encoding the data, so using the full 8MiB of PSRAM should only be possible at lower speeds, maybe 20MHz - and even then this would not be even half a second.

[gusmanb]

Not "a couple" of bytes, for SPI you can perfectly sample many kilobytes of data if properly configured.

[RudolphRiedel]

I meant a couple of bytes per frame, like two or three, the BT820 I am currently working with have 3 bytes for the most simple frame, 14 bytes per frame to read a 32 bit value and several frame lengths in between and beyond that.
Well, using burst mode might give still give me something meaningfull to look at running at 50Mhz, I will check that.

[gusmanb]

If you configure the burst size to capture a single byte, even if the data is longer it will be properly captured, the trigger takes a single cycle to be rearmed, so if you capture two cycles per signal period the capture will still be correct even if the burst ends in the middle of a transfer, when the trigger is rearmed it will have a single sample for that period but still the correct data.

[RudolphRiedel]

My boards are here and working with a slightly modified 6.5 firmware:

And I have to say, it is really useable with capturing in "Burst mode":
test4.zip

That captures a lot of SPI traffic.

The only thing I am missing from these captures are how long the pauses between the frames are for the timing between the frames.
There is a "Measure delays" option, but I am not sure what it actually does and it only works up to a "Burst count" of 254.
Would be sweet if the number of samples between frames could be saved somehow.

[mengstr]

As an alternative - would it be possible to increase the sample depth by using one RP2350 per channel? They are silly cheap so having 16 of them on a PCB wouldn't make a huge dent in the wallet.

But for it to really increase the samples then we'd need to shift 8 samples into a single byte before storing it into RAM. It would for sure be nice to have 4M samples, but I seem to recall you previously said that isn't possible to do that.

[gusmanb]

Using one RP2350 per channel yes, it will be possible to extend it making the PIO to shift a single bit and then configuring the autopull to 8 bits, but then you will be restricted to a single bit pattern trigger and the captures will always be forced to be multiples of 8 (this is the least of the problems). In any case it will be impractical, if you want 24 or 48 channels we are talking of a massive board that will be really expensive and then it makes no sense.

The only feasible possibility that I'm starting to play with is implementing PSRAM, this will restrict the speed to around 20Mhz and 8 channels per device, but will get to 8M samples. If this works then it will be possible to start reducing the captures to 4, 2 and 1 channels per device and that would multiply the speed and the capture size: 40Mhz 16M samples for 4 channels per device, 80Mhz and 32M samples for 2 channels per device and 160Mhz 64M samples for 1 channel per device. With this I can see a board with four RP2350, 32 channels max and capturing 32 channels at 20Mhz, 16 channels at 40Mhz, 8 channel at 80Mhz and 4 channel at 160Mhz, but still all of this is speculation, I got the PSRAM two days ago (I bought a pimoroni a long ago but sadly it came with the PSRAM dead... 😞 ).

[mengstr]

[Edit: added picture] The PSRAM is probably the way to go.
But 24 channels on a 100x100mm 4L board should fit just fine, the board in the image doesn't have the caps nor the voltage translators but they could probably easily be added considering the RP's could be squeezed a lot. In worst case the translators could be put on a small mezzanine board. 5 pcs of 100x100 four layers is only $7 so it will not be a problem from a cost perspective.
The multiple-of-8 is definitely not an issue. And I guess the trigger pattern issue could be solved with having one extra RP that is responsible for the trigger detection and it then kickstarts the data collector RPs'.

[gusmanb]

To take this route, it would be better just go for a FPGA, there are things like the Tang Primer with 20KLuts and 128MB of DDR3 that costs 26€, with that would be possible to create a monster of analyzer, and in fact I have one, the problem is that I'm not well versed using FPGAs, my area of expertise is programming and I do not have for now enough time to learn properly how to use them, if anyone with FPGA expertise wants to join and help to design it will be more than welcome to join the project, but for now I'm a single developer and I do what I can 😄

[RudolphRiedel]

Hrm, just routing it the way it is would be a nightmare on it's own.
But what about USB? Was the plan to add 24 USB sockets? Or just one and several USB hub chips?

[gusmanb]

Hrm, just routing it the way it is would be a nightmare on it's own.

Agreed.

But what about USB? Was the plan to add 24 USB sockets? Or just one and several USB hub chips?

No, this is something that already have in mind for the monolythic analyzer that I'm preparing, there would be single master with USB connected, and as there would be many free IOs on each device it is trivial to use a PIO to do parallel transfers from one MCU to other, so the master would send the data from all the MCUs.

[mengstr]

I can't see it as a huge routing problem. Only a single trace from each RP would be routed down to the connector, that could be done on the bottom layer. The two mid-layers handles gnd and vcc. And the top layer routes the decoupling caps and the signal between the RP's. That should be pretty clean and nice. Length matching is basically a non-issue. Most LA specs says that the samples allows for 1 sample skew, at 400 MHz I think that means that we need to match lengths to like 300mm. Even if we go bonkers and say we want to be within 10% of the rise time the requirement is not more than 10mm matching. But there is still plenty of room on the bottom for matching to 1 ps ;-) Sent with [Proton Mail](https://proton.me/mail/home) secure email.

…

On Sunday, 27 July 2025 at 20:01, Agustín Gimenez Bernad ***@***.***> wrote: > Hrm, just routing it the way it is would be a nightmare on it's own. Agreed. > But what about USB? Was the plan to add 24 USB sockets? Or just one and several USB hub chips? No, this is something that already have in mind for the monolythic analyzer that I'm preparing, there would be single master with USB connected, and as there would be many free IOs on each device it is trivial to use a PIO to do parallel transfers from one MCU to other, so the master would send the data from all the MCUs. — Reply to this email directly, [view it on GitHub](#280 (reply in thread)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AACPNTXT3MQILE4YNLY5I3L3KUHYFAVCNFSM6AAAAACCO3X2JCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGOJQGI4TIMI). You are receiving this because you commented.Message ID: ***@***.***>

[RudolphRiedel]

I did a new revision of my board, ordered it and then released it in a new repository: https://github.com/RudolphRiedel/8x-Logic-Analyzer
Maybe this will be a pull-request someday when the v6.5 is finalized.

[RudolphRiedel]

And my second batch of boards is here:

To my surprise, JLCPCB already populated these with the new A4 step of the RP2350.