Forum: GNU Radio Bit shift sync error with DPSK

Posted by Chris Biow (Guest)
on 2012-12-31 00:05
(Received via mailing list)
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?

The GRC file is at
https://docs.google.com/open?id=0B56aEJNJrwBAX2NhMHczdGhUejA


TIA,
 Chris
Posted by Josh Blum (Guest)
on 2012-12-31 05:32
(Received via mailing list)
On 12/30/2012 05:04 PM, Chris Biow wrote:
> 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?
>
> The GRC file is at
> https://docs.google.com/open?id=0B56aEJNJrwBAX2NhMHczdGhUejA
>
>

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.

-josh
Posted by Tom Rondeau (Guest)
on 2012-12-31 20:21
(Received via mailing list)
On Sun, Dec 30, 2012 at 6:04 PM, Chris Biow <ka4akq@biow.org> wrote:

> 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.

Tom
Posted by Chris Biow (Guest)
on 2013-01-01 19:58
(Received via mailing list)
Thanks, Josh and Tom. Those were the pointers I needed. It's fixed after
adding packet encode/decode, plus getting symbol lengths correct.

Tom's response from March
(http://permalink.gmane.org/gmane.comp.gnu.radio.ge...) was 
helpful
in providing a working GRC example that reliably receives what it 
transmits.
Please log in before posting. Registration is free and takes only a minute.
Existing account (Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
No account? Register here.