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
on 2012-12-31 00:05
on 2012-12-31 05:32
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
on 2012-12-31 20:21
On Sun, Dec 30, 2012 at 6:04 PM, Chris Biow <email@example.com> 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
on 2013-01-01 19:58
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.