Ah! I'll take the freedom of mentioning your StackOverflow question here: http://stackoverflow.com/questions/37042209/receiving-data-using-aux-cable-on-gnu-radio Because it contains an image of your receiver.
Best regards, Marcus On 05.05.2016 15:05, Marcus Müller wrote: > 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
