Re: [Discuss-gnuradio] gr_unpack_k_bits_bb, its inverse, and higher order constellations

[Mattias Kjellsson]

Mattias Kjellsson wrote:
> Tom Rondeau wrote:
>   
>> On Thu, Mar 4, 2010 at 2:13 PM, Mattias Kjellsson <address@hidden> wrote:
>>   
>>     
>>> Tom Rondeau wrote:
>>>     
>>>       
>>>> On Thu, Mar 4, 2010 at 11:38 AM, Mattias Kjellsson <address@hidden> wrote:
>>>>
>>>>       
>>>>         
>>>>> Tom Rondeau wrote:
>>>>>
>>>>>         
>>>>>           
>>>>>> On Thu, Mar 4, 2010 at 10:28 AM, Mattias Kjellsson <address@hidden> 
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>           
>>>>>>             
>>>>>>> Eric Blossom wrote:
>>>>>>>
>>>>>>>
>>>>>>>             
>>>>>>>               
>>>>>>>> I assume that you mean 1 byte per symbol.
>>>>>>>> I suggest that you create *_ci and *_ii versions that handle 32-bits.
>>>>>>>>
>>>>>>>> Eric
>>>>>>>>
>>>>>>>>
>>>>>>>>               
>>>>>>>>                 
>>>>>>> You are correct, one byte per symbol. Or one symbol per byte, whichever
>>>>>>> way one wants to look at it.
>>>>>>> To clarify what the custom block does is that it takes K bytes with 1
>>>>>>> significant bit (in lsb, from a glfsr or similar) and turns it into 1
>>>>>>> byte with K significant bits. Then it's just to feed these new, "packed"
>>>>>>> (is this the word for it?), bytes into the chunks_to_symbols_bc- block,
>>>>>>> producing one symbol for every byte.
>>>>>>>
>>>>>>> Is this really stupid, or has it just not been done yet? I assume that
>>>>>>> there are more people working with more signal- points than two in their
>>>>>>> constellations. But at the same time it seems like I'm wasting a lot of
>>>>>>> resources on copying bytes with only two or three (qpsk, qam16)
>>>>>>> significant bits in them...
>>>>>>>
>>>>>>>
>>>>>>> //Mattias
>>>>>>>
>>>>>>>
>>>>>>>             
>>>>>>>               
>>>>>> Have you looked at
>>>>>> gnuradio-core/src/python/gnuradio/blks2impl/dqpsk.py (and qam8, qam16,
>>>>>> qam64, and qam256.py)? They handle the modulation and demodulation
>>>>>> parts of the TX and RX. We don't have a good synchronization scheme,
>>>>>> but I think these do what you want.
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>>
>>>>>>           
>>>>>>             
>>>>> I know of them, and have looked at them, but nothing more. Since I don't
>>>>> speak python very well, I try to do everything in c++.
>>>>>
>>>>> I have tried to use pilots mixed in every few data- symbols and
>>>>> compensate the data- symbols using these known symbols. I'm getting kind
>>>>> of good results, although I think the custom early/late gate sampler I
>>>>> wrote has a settling time way to long  (between 900 and 3000 symbols
>>>>> depending on which constants I put in). I'll try to rewrite the M&M-
>>>>> sync- block to utilize the slicer_45deg(), and see what results I get
>>>>> with that. From what I can tell from the paper pointed to by the header-
>>>>> file, the optimized M&M- loop should be able to handle at least QPSK,
>>>>> and have a way shorter settling time than 900 symbols.
>>>>>
>>>>> I think the pilot- compensation code should still work and compensate
>>>>> any screw to the constellation.
>>>>>
>>>>> I'm getting all exited just writing about it ;) I'll let you know how it
>>>>> goes.
>>>>> //Mattias
>>>>>
>>>>>         
>>>>>           
>>>> Matt and I wrote a resampler based on polyphase filterbanks a few
>>>> months ago. It's called gr_pfb_clock_sync_xxf (in the filter
>>>> directory). It works really well for any PAM signal (we've tested it
>>>> with PSK and QAMs successfully). You can see how its used in the new
>>>> dbpsk2.py and dqpsk2.py files.
>>>>
>>>> Tom
>>>>
>>>>       
>>>>         
>>> I will have a look, I haven't had the instant success I was hoping for
>>> with the M&M- loop as I hoped... It might have something to do with the
>>> parameters, but I doubt it, since I see the constellation alright, but
>>> it still demodulates the symbols into bits incorrectly, ie. the loops
>>> have locked on a rotated constellation, and/or the compensation with the
>>> pilot- symbols doesn't do the trick/ is done incorrectly. Maybe if I
>>> stop and think about it some more. But that'll be tomorrow, since it is
>>> way past office hours here.
>>>
>>> Mattias
>>>     
>>>       
>> Yes, at this point, the constellation is locked, but it's just locked
>> with any 90 degree phase ambiguity (or 180 if bpsk). None of the sync
>> loops understand this, so you'll probably have to map the symbols for
>> the given rotation to the correct (transmitted) rotation.
>>
>> Tom
>>   
>>     
> I have now read the code, and tried it out a bit.
>
> A thing, just code- wise, I saw and wanted to ask about:
> Lines 49 and 57 in gr_pbf_clock_sync_ccf.cc,
> iosig is a std::vector from line 49, is there a reason that on line 57,
> there is a "4" instead of iosig.size() ?
> Or are these numbers just coincidently the same?
>
> Also I got this "error":
> pilot_reveiver: ./gr_buffer.h:123: unsigned int
> gr_buffer::index_add(unsigned int, unsigned int): Assertion `s <
> d_bufsize' failed.
> Aborted
>
> Which is new to me... I have isolated it to the the gr_pbf_sync_ccf-
> block. Since I don't see the error if I don't connect this block.
>
> This is how I create the block:
> d_symbol_extractor = gr_make_pfb_clock_sync_ccf (d_sps, 0.1, tr_taps,
> nfilts, nfilts/2, 0.1); where,
> d_sps = 8
> tr_taps = gr_firdes::root_raised_cosine(nfilts, nfilts, 1.0/d_sps, 0.5,
> ntaps);
> nfilts = 32;
> ntaps = 11*(d_sps+nfilts);
>
> By looking at the "error outputs, outputs[1->3]" I get 9 points of data
> (samples_per_symbol + 1) out of  gr_pfb_stync_block::work() by the looks
> of them it seems like it is some sort of transitioning going on on the
> first and third output, and a "swinging" output that has just stabilized
> on the second. Ie. the first and third output are [0 0 0 0 0 0 0 0 x]
> where x ~ 6e4 or ~ 6e5, and on the second output there are two
> consecutive output samples that are equal ~10.
>
> The thought that the error stems from a "transition- state" is also
> supported by the fact that there is no errror produced as long as there
> is no input- signal to the usrp, but when that comes on, the program
> almost immediately exits with the above error.
>
> I guess I have done something wrong, since this code should be tested by
> now, right?
>
> Best regards,
> //Mattias
>
>   
Sorry, I just saw that I wrote the last message off- list.

Anyway, I have searched some more in the causes of this error. I took
the easy way out and looked in gr_buffer.h at line 127. and Changed this:
Approximately around lines 115->130 in gr_buffer.h
unsigned index_add (unsigned a, unsigned b){
unsigned s = a + b;
    /*if (s >= d_bufsize)
           s -= d_bufsize;*/
    while(s>=d_bufsize){
        s-=d_bufsize;
    }
    assert (s < d_bufsize);
    return s;
}

I assume this is not the way to do this, but it gets rid of the error-
message... But since I have changed in the library to make this specific
block not produce an error... It just seems like doing things backwards.
But then again, this code- change assures that s<d_bufsize, but is it
always correct to do this? I guess not, but I'm not sure.

It still produces segmentation faults though, which are off unclear
origin. It wasn't there before I tried the gr_make_pfb_clock_sync_ccf -
block, but than again, it might be something hidden in my custom code
that has popped out on the surface all of the sudden when the soundings
to these blocks have changed.

Regards
//Mattias