Hi Haaris, with "aux cable", you're referring to an audio transmission? > The point is that the symbols are always recovered correctly, but the > dynamic amount of junk recovered before the constellation locks itself > makes the pack 8 bits block work differently. (this is what I think is > happening) Exactly! Since there's no way for the receiver to know when the transmitter started transmitting, it decodes stuff before there's actually anything to decode.
In essence, you need some kind of preamble or so to tell your receiver when to start – side effect of having something like that would be that you could correct some things (the two sound cards don't share the same oscillator, which leads to a symbol rate offset, and a center frequency offset). I'm not quite sure about the right approach here; we used to have "correlate access code", which you can just tell to look for a specific streams of 0s and 1s, and throw away stuff before, I think. But also, we deprecated that, because it had some fundamental architectural drawbacks; don't know what I should really recommend in this scenario. Could you maybe export your flow graph (if you made it in GRC; File->Screen Capture) and share it with us? Best regartds, Marcus On 05.05.2016 03:09, Haaris wrote: > Hello all, > > I am trying to transmit data using aux cable from one laptop to another. > The modulation scheme I am using the PSK mod block is DQPSK. > The problem is that while recovering data I have to set a specific > value of delay to recover the original data back. > Sometimes no delay is needed, while at times some constant value is > needed. > The point is that the symbols are always recovered correctly, but the > dynamic amount of junk recovered before the constellation locks itself > makes the pack 8 bits block work differently. (this is what I think is > happening) > Is there a workaround or a simple way to fix this problem e.g dynamic > delay of some type? > Any help will be appreciated. > > > > _______________________________________________ > Discuss-gnuradio mailing list > 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
