Hi Rich, Thank you for your reply. Let me mention right away that the problem here was embarrassingly simple: I had endinannes set to LSB, changing to MSB fixed the issue..
But to answer your question, while in debug mode the mod is directly connected to the demod. So no phase error, hence I unplugged costas for the time being. In a real case, which worked ok in 3.6.x with a psudo-random stream and N210's, I had the following: rx in -- power squelch -- agc -- FLL -- PPCS -- CMA equalizer -- Costas -- demod -- filesink This does not fix the costas phase ambiguity, but certain corrected most channel offsets. so I am still at odds as to how to correct sudden constel rotations. maybe a short training symbol, adjusting costas output in pi/2 increments (qpsk). in fact the data is there, just needs to be decoded again with the right phase rotation. I'll post in a separate thread once I poke a bit more. And any ideas are welcome of course... Thanks, Arik ________________________________ From: Richard Bell [richard.be...@gmail.com] Sent: Thursday, February 18, 2016 12:58 PM To: Landsman, Arik Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] non-diff QPSK symbol sync, improper alignemnt/errors using real msg What are you doing to handle the phase ambiguity that diff encoding is intended to fix? Rich On Wed, Feb 17, 2016 at 2:35 PM, Landsman, Arik <arik.lands...@tufts.edu<mailto:arik.lands...@tufts.edu>> wrote: Hello Folks, I am debugging a flowgraph of QPSK without diff encoding. The aim here is to tx messages between two N210's, as a starting point for a heterogeneous networking project. long story short, I am seeing an issue sending/receiving a real message within the same flow graph (just direct connection to the Rx portion) Please read on.. The Tx msg is: "00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4B 4B 4B 4B 20 20 48 65 6C 6C 6F 20 57 6F 72 6C 64 20 20 4B 4B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00" where, "4B" is a rotating vector to allow costas to lock (not used here while in debug) "20 20 48 65 6C 6C 6F 20 57 6F 72 6C 64 20 20" = " Hello World " "00" is just padding (I tried a psudo-random sequence instead, 4096 bits long on either side of msg, similar results) the rx msg is (consistently across runs): "C0 03 3C 3C 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 48 4B 4B 4B 13 10 48 98 DA D8 D8 13 A8 DB 3B D9 98 10 10 48 4B 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00" Added 4bit delay to align the samples before the file sink. Note that "4B" is ok, but the 0x20 expected right after is typically passed as 0x10. rest of the msg is scrambled, consistently. My signal chain is as follow: file source -- const mod (see const object below) -- throttle (320k) -- Polyphase CS (or Clock Rec MM, same result) -- const soft decoder (using same const object) -- binary slicer / bit packing / file sink const rect object: sym map: digital.psk_4()[1] // evals to [0,1,2,3] points: digital.psk_4()[0] // evals to [(-1-1j), (1-1j), (-1+1j), (1+1j)] [..] Soft Decision LUT: 'auto' Polyphase Clock sps: 8 taps: firdes.root_raised_cosine(32, 32, 1.0, 0.5, int(5*sps*32)) *rest is at default, LB = 2*3.14/100 excess bw = 0.5 when on repeat, the binary out of the soft decoder looks crisp, easy for binary slicer to decide. not sure what RRC taps are used in the Const Mod block - maybe the RRC in the PPCS doesn't match. Seems close enough though, same as in similar examples that use the Const Mod block. again, decoded binary looks clean. Few questions... had anyone seen this before, i.e. dropped bits or incorrectly decoded symbols W/O using Costas? any thoughts on new debug directions? the two active blocks are the Constel Mod and the PPCS (or MM, same result) Did anyone in general try non diff-encoded QPSK transmission using a real message? Seems like diff encoding was laways ON while QA'ing the psk blocks. I haven't seen an example online as of yet (although plenty of good material that uses psudo-random) Thank you in advance! Arik Landsman _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
