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 https://github.com/gusmanb/logicanalyzer/issues/111#issuecomment-2153124578, 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 https://github.com/gusmanb/logicanalyzer/issues/111#issuecomment-2156408967, 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.

[tshcherban]

Another dumb question regarding firmware: how much CPU is involved in the capturing process? Is it just orchestrating DMAs and PIOs and then waiting for the results? If so - is it possible to do some basic RLE over captured buffer? To store only edges along with idx and not 100_edge_512 samples.

[gusmanb]

The CPU is doing nothing, all the capture is done by the PIO and DMAs with zero usage of the CPU in it, but it is impossible to apply in real time the RLE encoding.

The buffer is a ring buffer, I have four DMAs chained and they iterate over all the memory because the device is capturing all the time, it does not start when the trigger is detected because then it would be impossible to have pre-samples and is a must, so you don't know where it started and where it ended until it finalizes the capture. Also, the thing is moving 3.2Gbps of data when it operates at 100Mhz, it is impossible for the CPU to follow that speed, and finally even if it could there is no way to notify to the PIO of the free memory to increase the number of samples to capture.

[tshcherban]

Okay, now i see how it works, thanks.

[tshcherban]

Added a possibility to collapse/expand gaps between bursts (works with those firmwares you've provided). Can open PR if you think that might be useful. la-burst-gap-collapse.zip

[gusmanb]

Hmmm, strange, it does not run, do the PR and I will check it :)

[tshcherban]

you mean the app itself does not start at all? Anyway, my changes

[gusmanb]

Ok, it is really cool, but I think you didn't understood how the bursts work, let me explain.

When you specify the capture parameters you give "presamples" and "postsamples", the "presamples" are the ammount of samples that are captured before the trigger happens, and the postsamples is the ammount of samples that are captured after the trigger. The trigger is an event that last a single sample.

Then, after the first ammount of pre/post samples are captured the device stops capturing, rearms the trigger and then, when the trigger condition is detected again it resumes the capture and captures the number of samples specified in "postsamples". Basically where you find the marker one burst has ended and other has started and the marker is giving you how much time has passed since the capture stopped and restarted.

For example, look at this:

According to your guide 580ns passed from the high-to-low to the low-to-high where the burst has ended and restarted. That's not correct.

Between that two changes the device has captured 2,41us, to taht you must add the "gap" caused by the burst:

So in this case the real "distance" between those events would be 2.41uS + 580ns = 2.99us

Finally, a warning, the expand (not sure how it works, I see that some are expanded, others don't) can generate a massive ammount of data, literally, the first idea that I had was to "reconstruct" the samples adding empty ones, more or less like you are trying to do, but on my tests I hung my computer immediatelly, is as simple as sampling at 100Mhz and leave gaps of 1 or 2 seconds between bursts, that generates 100 million of samples per second, so you can imagine what happens :D

If you correct the measuring I would love to include it, is really cool, but it must take into account any number of bursts that happen between measures (it can happen that the burst ends while the trigger condition is true, so it is rearmed and continues capturing immediatelly but there are two samples of delay always as it is the time the trigger takes to be ready again), basically is to measure the time that happens between high/low change and add the time of any burst that is found in between.

Cheers!

[tshcherban]

overall I understood the 'burst' logic.

According to your guide 580ns passed from the high-to-low to the low-to-high where the burst has ended and restarted. That's not correct.

Thats a mistake. I've left a 'debug' code to visually see If im measuring burst delays correct, since thats a test PR, not the ready-made feature. Will correct it.

it can happen that the burst ends while the trigger condition is true, so it is rearmed and continues capturing immediatelly but there are two samples of delay always as it is the time the trigger takes to be ready again

Figured out from practice, those are to be expanded in a normal way automatically and without a grey indicator of 'gap':

Is there any limitation of postsamples size? Can it be lower, i.e. 256/128? so the Pico can capture even more events.

[gusmanb]

The quantity of bursts is limited to 254, there is no more memory to save timestamps.

El mar, 11 jun 2024, 7:05, Taras Shcherban @.***> escribió:

overall I understood the 'burst' logic.

According to your guide 580ns passed from the high-to-low to the low-to-high where the burst has ended and restarted. That's not correct.

Thats a mistake, I've left a 'debug' code to visually see If im measuring burst delays correct. Will correct it.

it can happen that the burst ends while the trigger condition is true, so it is rearmed and continues capturing immediatelly but there are two samples of delay always as it is the time the trigger takes to be ready again

Figured out from practice, those are expanded in a normal way and without a grey indicator of 'gap'.

Is there any limitation of postsamples size? Can it be lower, i.e. 256/128? so the Pico can capture even more events.

— Reply to this email directly, view it on GitHub https://github.com/gusmanb/logicanalyzer/issues/111#issuecomment-2159800665, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7FZANNXLRMMFRKKE73WDTZG2APZAVCNFSM6AAAAABI4Y75VCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJZHAYDANRWGU . You are receiving this because you commented.Message ID: @.***>

[tshcherban]

Finally, a warning, the expand can generate a massive ammount of data

Will add a warning.

Potentially to avoid that - you can move from storing and rendering every single sample to just store edges, that would reduce the crapload of bytes to the amount of changes, which cant be more than 131072 if coming from the Pico.

Also transfering those repeated zeroes does not make too much sense but that's not a problem.

[tshcherban]

quantity of bursts is limited to 254

If you lower postsample size - it would fit more bursts unless there is some DMA/hardware related minimum

[gusmanb]

No, there is not enough memory, it does not matter the burst size, the buffers must be constructed statically (remember that there is a 128Kb ring buffer being written all the time and a buffer for the burst timestamps) and each burst consumes 4 bytes, it is already consuming 2Kb, more bursts would increase that size and there is not enough free memory.

El mar, 11 jun 2024, 7:15, Taras Shcherban @.***> escribió:

quantity of bursts is limited to 254

If you lower postsample size - it would fit more bursts unless there is some DMA/hardware related minimum

— Reply to this email directly, view it on GitHub https://github.com/gusmanb/logicanalyzer/issues/111#issuecomment-2159810274, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7FZAN4WBETTYS3G4FR6Y3ZG2BV3AVCNFSM6AAAAABI4Y75VCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJZHAYTAMRXGQ . You are receiving this because you commented.Message ID: @.***>

[tshcherban]

What datatype do you use to store the timestamps? For now i cant capture sequence which contains delay longer than 58 ms reliably. From time to time it reports 0 delay between bursts. Either some overflow or other bug preventing timing report

Those pulses are 2 us wide and coming with a ~70 ms period (not accurate because i used arduino and a simle delay for timings)

[gusmanb]

It is using a UInt32_t, it increases each tick, so it should be enough for 21 seconds, and I also took care of rolls so it should be good up to 42 seconds.

Will test it this afternoon.

On Tue, Jun 11, 2024 at 8:05 AM Taras Shcherban @.***> wrote:

What datatype do you use to store the timestamps? For now i cant capture sequence which contains delay longer than 58 ms.

— Reply to this email directly, view it on GitHub https://github.com/gusmanb/logicanalyzer/issues/111#issuecomment-2159865671, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7FZALRH4NQAMQG7PW3EHLZG2HRHAVCNFSM6AAAAABI4Y75VCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJZHA3DKNRXGE . You are receiving this because you commented.Message ID: @.***>

[tshcherban]

Fixed measurement and warning

[gusmanb]

Perfect.

Here is a version with the measurement fixed, there is a bug in the software and other in the firmware.

https://mega.nz/file/DTIx3S4a#Yz_iUy7lybUGhpexGeeQiaJAuSm679aNpFIp4RCotOo LogicAnalyzer.zip

I have noticed something, you have updated the code from a non-existing one, I assume you decompiled the executable that I sent you and added the missing pieces in order to make it to work.

That's ok, but be aware that things will still change, this is a proof of concept, I need to do the final development (create proper structures, update all the tools including the CLI ones, etc) so things will break.

Continue working in your branch if there is anything that you still want to change and once I complete integrating this functionality I will manually merge them, I expect to be able to do it this weekend, right now I'm really busy with my job and will not be able to continue with this at least until the weekend.

Leave the PR in place as it makes easier to follow the changes and will be useful when I do the merge :)

Cheers.

[tshcherban]

Of course, my PR initially was just for a PoC to see a long pauses between bursts. UPD. you may publish your unfinished work into a separate branch, so i can adopt the changes faster.

[tshcherban]

And sorry for the decompiling part, I was just eager trying it since I use that logic analyzer to figure out some stuff.

[gusmanb]

And sorry for the decompiling part, I was just eager trying it since I use that logic analyzer to figure out some stuff.

No worries at all, this is an open source project and anyone can do whatever wants with it, I was just commenting so you were aware :)