I’m trying to get a simple PSK loopback working in GRC, File Source →
DPSK
Mod → DPSK Demod → Unpacked to Packed → File Sink.
On Ubuntu 12.10 x64 (build-gnuradio a few days ago), the sink file winds
up
with leading 7 bytes x00, 3 bytes plus one bit noise, four mangled bits,
and
then my correct bitstream. But the odd bit causes the entire remainder
of
the bitstream to be right-shifted by one. Throttling doesn’t seem to
have
any effect.
Interestingly enough, using MSWin7, I get 6 bytes x00, 2 bytes noise, 26
bytes mangle, and then a correctly aligned stream of bytes (other than a
mangled sequence from about bytes 100-107).
Am I missing something to provide symbol timing recovery?
This may not be 100% of your issue, but I cant say that with certainty
that the states of the various timing recovery are initialized or zeroed
at constructor time. So different runs or different OSs could yield with
different results.
Now, the real issue is there is no framing or frame recovery blocks in
this flow graph. So the recovery side doesn’t know what symbol starts a
byte, so you could have bits sliding across byte boundaries in the
unpacked to packed, even in this simple example.
Interestingly enough, using MSWin7, I get 6 bytes x00, 2 bytes noise, 26
Chris
Chris,
What you are seeing is the result of the group delays of the digital
filters. Both the modulator and demodulator have filters in them that
each
add their own delay. The system also works on symbols that are converted
to
bits. It doesn’t know about or care about byte alignment. Some of the
packetizing/framing blocks we have use an access code to find the start
of
the frame and then know how to appropriately align for the byte
boundaries.