Hi Marcus, others, Actually things are not working on my side. I would be thankful if you could give some suggestion. The points on the constellation diagram come to be at max in an elipse of half major axis length = 0.02, while my constellation object takes the decision on 1+0j, -1+0j, 0+0j - which worked in simulation well.
When I change the decision boundary from 1,-1 to 0.02,-0.02 for the actual channel, I still don't get any decoded bits. Is it possible to please suggest something for me ? Right now, I am using the Polyphase synch block followed by constellation decoder as the only two blocks on receive side, instead of using the FLL-BandEdge block. Thanks, Abhinav On Mon, Oct 12, 2015 at 2:21 PM, abhinav narain <abhinavnarai...@gmail.com> wrote: > Hi Marcus, > I messed that up! I am not sure if formatting is correct in the copied > message, but yes I have emailed it to the discuss list now! > > Thanks, > Abhinav > > On Mon, Oct 12, 2015 at 11:16 AM, Marcus Müller <marcus.muel...@ettus.com> > wrote: > >> Hi Abhinav, >> I currently don't have the time to properly respond -- generally, it's a >> very good idea to reply to the mailing list rather than individuals. Could >> you do this for this mail? >> Thanks, >> Marcus >> >> >> On 10/12/2015 08:07 PM, abhinav narain wrote: >> >> Hi Marcus, >> >> >>> the problem is that you're not doing BPSK, really. It's an Amplitude >>> shift keying, if you want so. >>> >> That is partially true - in ASK absence of pulse is bit 0, but in my case >> bit 0 is inverted pulse and absence of pulse is a third symbol. >> I want to send across two different bits sparsely spaced in time using >> gnuradio hardware. >> >> Two things: >>> * you might want to consider what AGC2 does while you're transmitting >>> zeros -- it will increase amplification until noise scales up to signal >>> power. What you're getting after that will more or less be useless, unless >>> your AGC is really set to be slow (I don't think so, according to the >>> attack rate of 6/100). >>> >> Okay, I used it as this block is used in generic_mod_demod.py with these >> parameters >> >> >>> * you're throwing a FLL at your signal -- which would be fine, if there >>> was definitely a carrier. I don't see how that should work for a signal >>> that's zero most of the time. >>> >> Yes, I guess I need to do upconversion but I am right now just doing >> things in baseband. Even if I turn off the FLL Band-Edge block, I did not >> see any improvement in the output. >> >> * Assuming the polyphase clock synth did work with such a signal, the >>> resulting signal would still contain a symbol that was '0', and hence had >>> random phase (the phase of the additive noise at the sampling time). Hence, >>> the costas loop can't do anything reasonable about that. >>> >>> I see, I am vaguely familiar with costas loop, should I not use costas >> loop then? >> If I give order ==3 ( constObj.arity()) which is the size of >> constellation 0,1,-1, it doesn't work at all, hence I gave the parameter >> value as 2, and I get the previous output. >> After following your advice of increasing rolloff in RRC filter and sps, >> I get the following stable output, although it is scaled to -2,2. >> Please see the following image - (http://postimg.org/image/6kenur0ix/) >> constellation_after_channel_and_after_costas_loop.png >> >> If I understand you correctly, however, you *actually* want to do BPSK, >>> and the 0 symbol is just a "filler" in between symbols, right? >>> >> Yes! Exactly! >> >> >>> That might actually work, if you just increase the rolloff >>> duration/samples per symbol of your pulse shaping filter. >>> >>> Okay, I have increased the symbols, but the output of the decoder is >> wrong! Please see the image - (http://postimg.org/image/ngar9353z/) >> constellation_decoder_ouput.png. >> >> It should be equally spaced values of 1, 0 with a lot of 2s(representing >> (0+0j)s transmitted) in betweeen. >> I doubt the way I am using constellation decoder is the right way. >> I want the decoder to decode as the image attached - ( >> http://postimg.org/image/k0awzlq0h/ ) decoder_wanted.JPG >> >> >> So, I think it might be best to explain what kind of system you're trying >>> to build, so that we can understand that better! >>> >>> I am trying to build a covert system where I transmit very rarely so >> that it is difficult for someone to find out I am on the channel. >> >> Thanks for your response, >> Abhinav >> >> >> Best regards, >>> Marcus >>> >>> >>> On 10/12/2015 06:00 PM, abhinav narain wrote: >>> >>> Hi, >>> I am trying to transmit -1,0,1 { [1]+ 100*[0]+[-1] }, basically BPSK >>> lot of 0s filled in between at certain frequency. I have few questions. >>> "Constellation object" has 3 symbols ([1+0j,-1+0j,0+0j]) mapped to symbol >>> map-> [0,1,2] respectively. I agree that constellation with size 3 is >>> weird but that is what I want. I want the decision boundaries to be at >>> -0.5, 0.5 for bits and anything between that to be given symbol=2 which i >>> can discard later on. I am currently doing this in baseband, but I will >>> eventually trasmit at a some frequency X. >>> >>> I have the following baseband setup grc ( >>> http://postimg.org/image/8k7g1o375/ , grc file is attached). >>> I have few problems which I am unable to fix since yesterday - >>> 1) The constellation after channel is stable (as expected) but it goes >>> weird >>> after the polyphase clock sync and costas loop ( >>> http://postimg.org/image/pyg8h2vlh/ , attached image- >>> constellation_before_after_costas.png) and hence I don't get the expected >>> output of equally spaced 1, 0 in the decoder output ( >>> http://postimg.org/image/a58cc35cj/ , attached image- >>> custom_decoder_0_1_2_output.png) >>> >>> 2) If I set the order of costas loop as 3 (size of constellation) my >>> flowgraph doesn't work at all. I have used the parameters after reading >>> some example code >>> in gnuradio folders and web and i guess they are correct. Please >>> correct me if I am wrong. >>> >>> Thanks, >>> Abhinav >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing >>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> >> >
clock_4_receiver.grc
Description: application/gnuradio-grc
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
