PSK not being interpreted whilst ASK and FSK are fine

[pickeditmate]

Can someone please confirm whether Windows version has PSK working as it should for interpretation window?

Expected Behavior

interpretation window to show values underneath as phase changes

Actual Behavior

showing as either all zeroes or all ones

Steps To Reproduce

Took capture from a PSK device directly in to URH from the capture window.
saved signal and went to interpretation window
set parameters as required
tried with both autodetect and manually setting with the same end result

Screenshots

Platform Specifications

• OS: [e.g. Arch Linux] windows 10
• URH version: [e.g. 2.4.2] 2.9.3
• Python version: [e.g. 3.7] 3.9
• Installed via [e.g. pip] exe

[andynoack]

Whether PSK can be demodulated or not strongly depends on the particular phase changes in your signal. That means, it can work for someone else but not for you, or even the other way around.

I would like to ask the community for working or not working PSK examples. Please help us with examples!

[pickeditmate]

Thanks Andy, I'll see if i can grab examples from some community friends and wilp report back asap

[le0nidus]

https://mega.nz/file/FWpgWZ6A#B30ODFmwMBS9iDZYUBTsF72GIX8cYBcsoqWILIdvLXg

That's a non-working psk
There are 3 tx sessions in the file, the middle one is trash.

[andynoack]

Thank you very much! Can you provide us with the correct bit sequence of the first and third TX session?

[le0nidus]

Hey, I wish!
It's a signal I'm trying to decode..

[rumpeltux]

Here’s another example of non-working PSK

150-1-sample.complex.gz

With the default setting of costas loop bandwith=0.1 nothing is decoded at all. Below 0.06 something becomes visible, but the results don’t seem to match the actual signal.

For PSK signals, an IQ-view would also be more useful than the regular "Analog" view, otherwise it’s hard to tell visually if there’s a phase transition at a peak (see also #648).

For reference: in the inspectrum phase view (bottom graph) one can decode the signal manually based on the phase transitions (ignore the completely vertical green lines, they are just artifacts of this view)

[4ertus2]

One more not working PSK sample

psk-52ss.complex.gz

[andynoack]

A samples/symbol value of 10 seems plausible for this signal. Generally, for all PSK signals it is necessary to provide us with the expected bits, otherwise we are not able to look for possible mistakes in the decoding code.

[4ertus2]

A samples/symbol value of 10 seems plausible for this signal.

If you're talking about my signal above it's 52 samples/symbol. I've selected the 52 sample frame at first copy of the signal. Phase changes have 52/104/156 samples distances.
First of all it's not too hard to estimate samples/symbol if PSK + 1 bits/symbol selected. But there's also something very strange at the second copy of signal at the picture above. I've selected the first of auto decoded bit there. And it ignores specified samples/symbol at all. It says "316 symbols selected". There're 3 phase inversion in these 316 samples. But urh interprets this sequence as one symbol. It looks like autodetector ignores all the parameters I've set.

What autodetector is really doing? I expect that it:

1. Estimates samples/symbol by signal phase changes with sliding window and known bits/symbol
2. Finds first symbol position with fixed detected samples/symbol
3. Decodes sequence starting from found first symbol position and samples/symbol with specified error tolerance.

And one more thing. I'm trying to decode fixed byte sequence from device. If I miss some of first bits I do not need other ones. It's not about some streaming signal that could be decoded from any position. It looks like urh tries to extract something from the signals center. But in my case it should stop at the first place it cannot decode sequence with specified error tolerance.

[andynoack]

If you are not sure why URH does not see specific symbols, please use the demod view. You are able to see what URH sees at that particular position. Maybe some settings (e.g. Center) have to be adjusted or you see that the signal doesn't have a sufficient quality here. Of course there can be mistakes in the decoding code! When you identify such wrongly decoded parts, please crop them out and upload them together with the bits you are expecting.

The autodetector is another thing, however. Your ideas are good in theory but this isn't the way it works in practice. URH works good for so many signals because it is fault tolerant, i.e. it is sometimes very flexible regarding symbol length. This can produce problems in specific situations like yours but makes so many other signals work. We always wanted to make URH compatible with as much different signals as possible, that is why it is not an option to change this behaviour.

If you want to remove messages that begin with wrong bit sequences, I have good news for you! You can override URHs behaviour with custom decodings. Just create a script where you check the incoming bit sequences and remove every line that does not fit your needs. In a custom decoding call your external script and then apply your custom decoding to all messages of your signal.