huzaifazafar108 wrote:
>
> Sir,
>
> Repeat is set to yes. I guess this is not the problem. Also, without the
> USRP block (by sending the modulation output to the demoudalation input),
> everything is working the way it should.
>
> Best,
> Huzaifa
>
>
>
> Ben Reynwar wrote:
>>
>> For the vector source it looks like you're using [1,1,1,0,0,0].
>> Perhaps the rest is getting cut-off, but if not then I would change
>> this to use a long random vector for the testing. If you are using
>> [1,1,1,0,0,0] repeated then the four symbols won't be used with
>> similar frequency, which might make things more difficult.
>>
>> Also the differential encoding and decoding should be taken care of
>> within the DPSK mod and demod blocks, so that should be OK.
>>
>> On Sun, Apr 8, 2012 at 2:25 PM, huzaifazafar108
>> <
address@hidden> wrote:
>>>
>>> We just removed the throttle blocks and the same problem remains. Please
>>> let
>>> us know how to achieve symbol synchronization.
>>>
>>>
>>>
>>> huzaifazafar108 wrote:
>>>>
>>>> Dear John,
>>>>
>>>> Thank you for such a prompt reply. Okay, we will remove the throttle
>>>> blocks just now. But can you guide us how to achieve symbol
>>>> synchronization then?
>>>>
>>>> Best Regards,
>>>> Huzaifa
>>>>
>>>>
>>>>
>>>> John Malsbury wrote:
>>>>>
>>>>> You do not need to use throttles when using a UHD sink/source, because
>>>>> the device provides timing for the flowgraph.
>>>>>
>>>>> Remove the throttles and try again. If you still see the failure I'd
>>>>> say you are not achieving symbol sync.
>>>>>
>>>>> -John
>>>>>
>>>>>
>>>>>
>>>>> On 04/08/2012 01:58 PM, Huzaifa Zafar wrote:
>>>>>> Dear all,
>>>>>>
>>>>>> I am working with 3 people on a project involving GNU Radio and
>>>>>> USRP1.
>>>>>> We have tried to implement a simple point to point digital
>>>>>> communication system in GRC involving DQPSK modulation. Using a
>>>>>> vector
>>>>>> source we are sending a finite stream of zeros and ones (the vector
>>>>>> source has Repeat set to yes). On the receiver side, what we receive
>>>>>> is really very strange: The same stream of zeros and ones, but with
>>>>>> extra zeros in between our actual data. For example, we send three
>>>>>> ones and three zeros, but what we receive is a one followed by seven
>>>>>> zeros, another one followed by seven zeros, another one followed by
>>>>>> seven zeros, and then a zero followed by seven zeros e.t.c. We tried
>>>>>> to experiment more by using the 'KEEP 1 in N' block and the
>>>>>> 'DECIMATING FIR FILTER', but things are not working out the way they
>>>>>> should.
>>>>>>
>>>>>> I am also attaching a snapshot of the .grc file for your reference.
>>>>>> Please tell us the reason why these extra zeros are present between
>>>>>> our data bits, and the way to combat this effect (remember that the
>>>>>> decimating fir filter and keep 1 in N block are not showing the
>>>>>> desired output). Any kind of help is appreciated in advance.
>>>>>>
>>>>>> --
>>>>>> Huzaifa Zafar
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Discuss-gnuradio mailing list
>>>>>>
address@hidden
>>>>>>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Discuss-gnuradio mailing list
>>>>>
address@hidden
>>>>>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>
>>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>>
http://old.nabble.com/Problem-with-USRP%21-tp33653047p33653150.html
>>> Sent from the GnuRadio mailing list archive at Nabble.com.
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>>
address@hidden
>>>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>>
address@hidden
>>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
--