Complex trigger difficulties on picoscope 2000 2206B

Having problems ? let us know the details here
Post Reply
herobrine11892
User
User
Posts: 2
Joined: Fri Jun 25, 2021 5:49 am

Complex trigger difficulties on picoscope 2000 2206B

Post by herobrine11892 »

Hi! I've recently started developing an open-source data logging software for picoscope 2206B but there seem to arise some strange behaviours from the complex trigger and I wanted some second opinions.

The github repository for the code is: https://github.com/michael11892/picoscopeDataLogger

I setup a signal gen on my scope that creates a signal of frequency from 10Hz to 10KHz with a step of 100Hz every 10 milliseconds, which I pass to channel A and B using a split coaxial cable.

Trigger setup [Same exact setup is right now in main.py in the repo above]:
-Conditions:
-> Structure1 - A must be true (1), B must be false (2), dont care about the rest (0)
-Directions:
-> Rising upper trigger on channel A and B
-Properties:
-> A channel trigger - [1024 adc counts, 300 hysteresis, 1000ms auto-trigger]
-> B channel trigger - [1024 adc counts, 300 hysteresis, 1000ms auto-trigger]

This trigger setup should trivially always resort to auto-trigger because effectively I'm just feeding the exact same signal and asking the same condition to be true in one channel and false in another.

However, this doesn't happen. The trigger fires regardless of the conditions and I know that it's not auto-triggers fault here because the waveforms captured don't correspond to the expected waveforms based on the signal gen configuration I gave, (i.e. the consecutive waveforms are identical in frequency, even though if it was auto-trigger they should have been captured 1 second apart and thus should have had 1KHz frequency difference).

I later tried to just test only channel A with the same trigger conditions and to my dismay I found that regardless of what I set A in the conditions structure (true or false) it still triggered and even more confusingly, at -sometimes- rising and -sometimes- falling signals. The same pattern continued when I tried combinations of conditions for channel A and B, they just triggered no matter what. .

I have tested some flat examples and those worked fine. For example, when I just fed a flat 200mV signal to channel B and told it to trigger to some negative voltage, it didn't.

Using examples like these I tested the logic of the trigger and it seemed to work fine but with any use case that has even the simplest usable pulse it just fails and I have no idea why. Am I missing something here? I'd love to hear your input on this, thanks!

Update: After further testing I have come to the conclusion that its not the codes fault after all. The trigger has been confirmed to work with other, more composite, examples and after some tribulation the prevalent theory is that the signal splitter we're using in conjunction with the two channels causes a slight random delay between the two signals, which then allows for the aforementioned behaviour that we had been observing. More specifically, taking the previous example under closer inspection, we realise that if there is a delay in channel B in comparison to channel A, then when the rising trigger fires for A, it wouldn't have yet fired for B, thus satisfying the specified conditions and firing the entire logical trigger. I suspect that the faulty triggering at falling is explained by similar arguments, combined by a certain misconfiguration that was spotted and fixed after OP was made. So far no other issues seem to be appearing regarding the trigger but in light of this discovery, I wanted to ask,

How many samples does the trigger use to determine if the signal is rising or falling and how exactly does it determine that? Also, is there any way that we can add delay to the trigger, in the sense that; I want A to be rising and after that, in 10 ms, B must be falling, for example.

Post Reply