Capturing results inconsistent at F > 8 MHz #111
Comments
|
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: Cheers. |
|
Thanks for the explanation. |
|
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:
***@***.***>
|
|
I mean sending a time information about when trigger triggered after previous burst ended. |
|
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. |
|
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. |
|
Yes, I understand, that's more or less what I was explaining with the NMI, I will try to implement it. |
|
Regardless of the result, already done job is amazing, thanks a lot. |
|
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. |
|
Wow that was fast) 250 ns could be easily covered with just a 25 postsamples, so that jitter should not be an issue. |
|
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. |
|
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). |
|
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:
***@***.***>
|
|
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. |
|
Hi! Good news, I got it working with zero jitter, I got a bit of help in the Pico forums :) Here is a version that runs completelly from RAM. 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. |
|
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. |
|
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. |
|
Okay, now i see how it works, thanks. |
|
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. |
|
Hmmm, strange, it does not run, do the PR and I will check it :) |
|
you mean the app itself does not start at all? |
|
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! |
|
overall I understood the 'burst' logic.
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.
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. |
|
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
<#111 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA7FZANNXLRMMFRKKE73WDTZG2APZAVCNFSM6AAAAABI4Y75VCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJZHAYDANRWGU>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
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. |
If you lower postsample size - it would fit more bursts unless there is some DMA/hardware related minimum |
|
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
<#111 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA7FZAN4WBETTYS3G4FR6Y3ZG2BV3AVCNFSM6AAAAABI4Y75VCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJZHAYTAMRXGQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
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) |
|
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
<#111 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA7FZALRH4NQAMQG7PW3EHLZG2HRHAVCNFSM6AAAAABI4Y75VCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJZHA3DKNRXGE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Fixed measurement and warning |
|
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 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. |
|
Of course, my PR initially was just for a PoC to see a long pauses between bursts. |
|
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 :) |
|
Hi
Maybe if u dont have too much spare time - you could point out where the bug in firmware is? I can try temporary fixing it myself. |
Did you downloaded the software version from the link? It has the bug from the software fixed. https://mega.nz/file/DTIx3S4a#Yz_iUy7lybUGhpexGeeQiaJAuSm679aNpFIp4RCotOo Also, here is the firmware, I think in this version all is solved (sorry, I'm really busy these days with my job and don't remember exactly where I stopped, I think all was corrected...), if I recall it right the bug on the firmware only happened on the rollbacks of the counter and this version solves it. Cheers. |
|
Curious if you can benefit from one extra pio block |
If you check the readme I already have updated it according to the Pico 2, I have three on its way, we will see what improvements can be achieved with it :) I will also try the Risc-V cores, they may be more efficient handling the interrupts and solve the need of using the code in memory. |
|
Chiming in to say thanks. One funny thought i had while reading through this thread. |
Thanks for your words :) Well, it might be possible, the problem is that depending on how fast the bursts happen then the USB will not be fast enough to send the chunks before the buffer is full, if it is for sparse events where you expect gaps that last a couple of seconds it should be possible, but if the bursts happen in intervals of milliseconds or microseconds then the sampler would catch the USB very fast and would overwrite the data. But you gave me an idea... there are cases were you can expect these long delays, maybe a microcontroller is talking to a device in some events and then gets silent during a "long" period, I think I would be able to create a continuous mode that rearms everything once a chunk is sent, but the minimum delay between bursts will be determined by the USB speed. I will think about it. |
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"
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?
The text was updated successfully, but these errors were encountered: