Capturing results inconsistent at F > 8 MHz

[tshcherban]

Hi
I have STM32 set up to communicate with a DS18B20 via OneWire. Communication itself works, i can observe a correct temperature readings from the sensor.
I've attached RPI Zero W flashed with Your firmware to observe a communication. Started capturing on 2/4/8 MHz, worked as expected, I'm able to see all the bits and decode them into valid OneWire/DS18B20 commands.
However if I'm setting 10 MHz sampling - capture seems scrambled, cant decode. However communication itself works, because i can still see a temperature readings.
Can you point me what I'm doing wrong? Colud a dupont wires be the issue here?
P.S. command to start capture"

CLCapture.exe capture COM24 10000000 1 10 512 500 "TriggerType:Edge,Channel:1,Value:0" capture.csv

UPD observing a 2.5 MHz test signal from other MCU works at any speed, seems some wiring/capacitance issues.
I have also added a vcd export to your CLI program, that allows easier import into other programs. Don't you mind if i open a PR for it?
Also would be nice having a possibility to capture multiple bursts via UI.
UPD2 I have tried to capture a two-three periods of a signal which contains 0 for 20 us and then 1 for 10 ms using negative edge trigger. And 'low' part is captured ok, however 'high' width depends on the capture frequency.
how does analyzer handle multiple bursts? are 'whitespaces' between them filled with an empty samples or they are just cut out from the results producing concatenated series of bursts prepended/appended with a pre/postcapture samples?

[gusmanb]

Hi.

It is possible that you are seeing crosstalking, if the wires are too near or the grounding between the analyzer and the device is not properly set up it can cause problems.

Regarding the export format, of course, go ahead, any improvement is welcome :)

About the burst, you can capture them from the UI:

Finally, the burst works like this:
It will initialize the analyzer and wait for the trigger edge to happen, it will preserve the specified ammount of pre-trigger samples and will capture the specified post-trigger ones, then it will stop capturing anything until it finds again the trigger and will capture the ammount specified as post-trigger samples (including the trigger one) and will repeat this until all the burst are completed.
What you explain matches what the device does, you are specifying the number of samples you want after the trigger, the faster you sample less time you will see as more samples per second are captured, you should calculate how many samples want to capture in relationship to the time base used, for example, if you want to sample your full signal of 0/1 at 1Mhz then you should capture 11.000 post-samples to get the full signal and a bit of "idling", if you capture at 10Mhz then you will need 110.000 post-samples to view the same interval.

Cheers.

[tshcherban]

Thanks for the explanation.
Is it possible to send some information about 'how far is next burst from the previous one'? It would really help sampling relatively low speed signals with high precision, i.e. im capturing burst at 10 MHz, then next trigger comes XXX ns/ticks/ms/... after the last burst sample or last trigger or last whatever.
The reason for this - i'm trying resolve timing issues in communication protocol, so higher resolution is better, however seeing the whole picture would help to understand what happens in the whole frame, and not only first few milliseconds.
I did not play around with code for pico itself because it requires a lot of stuff to know about this controller, which i saw today for the first time.

[gusmanb]

Sorry, what do you mean? The trigger rearms immediatelly and has a precission of one sample, it will not get more precisse than that... El jue, 6 jun 2024, 20:14, Taras Shcherban ***@***.***> escribió:

…

Thanks for the explanation Is it possible to send some information about 'how far is next burst from the previous one'? It would really help sampling relatively low speed signals with high precision, i.e. im capturing burst at 10 MHz, then next trigger comes XXX ns/ticks/ms/... after the last burst sample or last trigger or last whatever. I did not play around with code for pico itself because it requires a lot of stuff to know about this controller, which i saw tosay for the first time. — Reply to this email directly, view it on GitHub <#111 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA7FZAOTXEDQWJEMODTWUW3ZGCRHRAVCNFSM6AAAAABI4Y75VCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJTGEZDINJXHA> . You are receiving this because you commented.Message ID: ***@***.***>

[tshcherban]

I mean sending a time information about when trigger triggered after previous burst ended.
I e. You detect somehow that current burst is completed, arm some timer and wait next trigger. Once trigger fires - you stop the timer and have a duration of 'pause' between bursts.
So the analyser send not only samples but also durations between each burst.

[gusmanb]

Ok, now it makes sense, you want the device to tell you how far apart are the bursts.

Right now is not possible, all the capture is done in the PIO and there is no timming information and I can't introduce a counter as it will slow the capture, to capture at 100Mhz I can only execute two assembler instructions per sample so it's very tight.

But, I may have an idea, I need to poke with the device NMIs, I haven't used them so it will need a bit of investigation, if I can trigger a NMI on the CPU from the PIO then it might be possible, a regular interrupt to the CPUs would not be good enough, as this can run in the W the interrupts can be disabled by the drivers and that would make the measuring very imprecisse, what would totally defeat the purpose of this functionality, but if I can trigger a NMI from the PIO then it could be possible to measure a precisse time between bursts.

I will check it next week.

Cheers.

[tshcherban]

I'm not certain about the available peripheral here and logic overall, however if there is a 'burst end' when sampling is stopped, you can signal the main program from PIO or even do a small job within that pio: set some timer for 'count up' indefinitely, and then on burst end you read the timer value and set it to zero.
So on every burst end, when capture is done you can read the timer value and store it somewhere.
The idea I'm talking is on the precise diagram below:

First value can be dropped because first burst is considered to be a zero-point

[gusmanb]

Yes, I understand, that's more or less what I was explaining with the NMI, I will try to implement it.

[tshcherban]

Regardless of the result, already done job is amazing, thanks a lot.

[gusmanb]

I have been toying with the NMI's and got it working, it has a jitter of +-250ns but is the best the Pico can achieve as it's the minimum time to react to an interrupt, when the delays between the signals are higher than 250ns the timming is perfect :)

Tomorrow I will implement the visualization and if I have enough time will send you a firmware and software to test it.

Cheers.

[tshcherban]

Wow that was fast) 250 ns could be easily covered with just a 25 postsamples, so that jitter should not be an issue.
If i expect some high speed - i just use large postsamples number, i.e 500, so 5k ns are covered. And if next trigger occurs right after that - +/-250 is 5% max error.

[gusmanb]

Ok, I have a test version.

It works like this: whenever there is a burst, at the sample where the bursts start/end you will see a marker, if you hover over the marker at the top bar it will display the interval between the end of the burst and the start of the next one.

To test it use this version of the software and this firmware.

I have been testing and I found the source of the jittering, is the comms interrupts, I could disable the interrupts but then if you try to abort the capture the device would hang up. On my tests while USB or WiFi are idle (more or less one second after the capture starts) the timming is perfect, in the range of +-5ns.

Next week I will update the CLI app and the capture save format.

Cheers.

[tshcherban]

As far as I understood - jitter is in range 250 ns? P.S. im not using WiFi at all, no need (at least for now).
Also another question, can the samples storage be increased by sacrifying channels count? Or mem access is 32bit-aligned and that wouldnt help?

[gusmanb]

Only if you are unlucky and got a comms interrupt at the same time that a burst ends, else It Will be 5ns Max. El dom, 9 jun 2024, 11:19, Taras Shcherban ***@***.***> escribió:

…

As far as I understood - jitter is in range 250 ns? P.S. im not using WiFi at all, no need (at least for now) — Reply to this email directly, view it on GitHub <#111 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA7FZAIRITBBZ5XD5TFWPALZGQMYRAVCNFSM6AAAAABI4Y75VCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJWGQYDQOJWG4> . You are receiving this because you commented.Message ID: ***@***.***>

[tshcherban]

Then I would just cover that 250 ns with a 1000 samples postcapture, so to have min 10 us after the tail edge (and between the bursts). In that scenario 250 jitter out of 10k wouldn't be a big deal. Will take a look at the custom built later.

[gusmanb]

Hi!

Good news, I got it working with zero jitter, I got a bit of help in the Pico forums :)
The problem was because of flash contention, when the USB was triggering interrupts and the NMI was triggered it was contended because there were flash accesses happening.

Here is a version that runs completelly from RAM.

LogicAnalyzer.zip

Next week will try to optimize the WiFi version, that one does not fit all in RAM and I need to try to create a linker script that moves the critical sections to it.

Cheers.