I i try that DQPSK schema myself, but i notice that in your image you have
Bits per symbol in packet encoder set to 4, but the help of packet encoder
says 2 for DQPSK.

I try 2, and i get no errors until the end, probably because of file
buffering.
--- sent.hex    2013-12-14 10:11:41.308775941 -0800
+++ got.hex     2013-12-14 10:11:52.269776677 -0800
@@ -62206,259 +62206,3 @@
 00f2fd0: 4db3 ace4 e63f eb53 3fb3 e20a 6cdf 85ab  M....?.S?...l...
 00f2fe0: 1a29 0ae6 3816 2e64 bd37 dc08 6982 379b  .)..8..d.7..i.7.
 00f2ff0: fd0d 6dc5 0d68 53e9 0384 8234 3af2 9861  ..m..hS....4:..a
-00f3000: 1625 7ce9 c0aa 64e6 9272 6ce2 9dce d524  .%|...d..rl....$
-00f3010: 1d0f 748e bcfb 88a8 f9ee 3504 1dd4 7204  ..t.......5...r.

bytes_sent file has 999424 bytes
and bytes_received has 995328 bytes.
The difference is probably that 1 million samples from random source isnt
even to the payload length of packet encoder.


On Sun, Dec 8, 2013 at 8:57 PM, Henry Jin <henry.ji...@gmail.com> wrote:

> Hi all,
>
> As per previous discussions, I have changed my design as shown in the link
> https://www.dropbox.com/s/8pw27f29qf5unuq/Screenshot%20from%202013-12-08%2021%3A39%3A05.png
>
> This time, QPSK and BPSK both works as I compared the files generated.
> However, I found two more problems:
> 1. When Error Rate module is enabled, the simulation can only be run for
> one or two seconds, then it gets stuck. This was observed by attaching a
> scope in the flowgraph. The display of the scope is never able to be
> updated. Just wonder why this happens?
> 2. When DPSK Mod and Demod blocks are replaced by QAM Mod and Demod, I
> find that many packets are missing in the receiver's decoded file compared
> to the file on the sender side. Except the missing packets, all other
> packets in the receiver's decoded file can perfectly match with the ones
> sent. So what has caused this issue? To make it better understood, I
> attached a screenshot comparing the two files from file sinks.
>
> https://www.dropbox.com/s/9203fvigi3wohmh/Screenshot%20from%202013-12-08%2021%3A52%3A48.png
>
> Please give me some suggestions if you have any thoughts. Thanks.
> Henry
>
>
> On Thu, Dec 5, 2013 at 2:39 PM, Henry Jin <henry.ji...@gmail.com> wrote:
>
>> Thanks for your effort in trying to help, Michael. I will continue to
>> study and if I managed to get it working, I will keep you updated.
>>
>> Henry
>>
>>
>> On Thu, Dec 5, 2013 at 2:23 PM, Michael Berman <mrberma...@gmail.com>wrote:
>>
>>> Henry,
>>>
>>> I looked at this and some of the underlying code, and tried to run your
>>> example with some modifications, but all to no avail as to what you are
>>> attempting to do.  Last time I did anything like this I ended up using the
>>> mod_pkts code (found in gr-digital/python/digital/pkt.py).  Maybe there is
>>> some insight in there that may shed light on what you are trying to do.
>>>  Sorry I couldn't be of more help.
>>>
>>> Michael
>>>
>>>
>>> On Wed, Dec 4, 2013 at 1:31 PM, Henry Jin <henry.ji...@gmail.com> wrote:
>>>
>>>> On Wed, Dec 4, 2013 at 12:13 PM, Michael Berman <mrberma...@gmail.com>
>>>>  wrote:
>>>>
>>>>> Looking at your flowchart in the original post, you have an Unpacked
>>>>> to Packed block after the demodulator, with bit's per symbol of 1.  This
>>>>> doesn't seem right to me.  I have never tried this with a random source
>>>>> like you have it setup, however there should be an Unpacked to Packed 
>>>>> block
>>>>> prior to the modulator and a Packed to Unpacked block after the
>>>>> demodulator.  These should also have bits per chunck values that 
>>>>> correspond
>>>>> with the bits per symbol of the modulator and demodulator.  You need to
>>>>> feed in the data in a chunk with the correct amount of bits that 
>>>>> correspond
>>>>> to the bits per symbol of the modulation scheme being used.  In the
>>>>> example, it looks like you are using QPSK, and therefore the bits per 
>>>>> chunk
>>>>> should be 2 (which is log2(number of constellation points)).  The 
>>>>> modulator
>>>>> and demodulator work with chunks of data where each chuck corresponds to a
>>>>> symbol.
>>>>>
>>>>
>>>> *If not using the random source, what other sources do you think it's
>>>> better? I know GLFSR source also perfectly fits into this scenario. You
>>>> also mentioned I have to attach a Unpacked to Packed block prior to the
>>>> modulator. But since in my flow, I already set the random source with
>>>> maximum being 256. That means it's already outputting packed bytes. Thus,
>>>> IMO, Unpacked to Packed block is not needed based on my settings. The
>>>> reason I set the Bits per Chunk value as 1 in the Unpacked to Packed block
>>>> after demodulation is that I notice in the source code, it says the output
>>>> of the demodulation block is unpacked byte with only one LSB being valid.
>>>> So In my understanding, it is independent of what modulations (BPSK, QPSK,
>>>> etc) I'm using. *
>>>>
>>>>
>>>>>
>>>>> For the Samples per Symbol, if I were transmitting over the air, I
>>>>> would raise this value to a little bit more than 2, just to ensure the
>>>>> receiver can lock onto the changes with given noise before the symbol
>>>>> changes again.  In this case of looping the modulator strait into the
>>>>> demodulator, this should work fine.
>>>>>
>>>>
>>>> *Thanks for the advice, I will take it. *
>>>>
>>>>
>>>>>
>>>>> One more thing I would look at would be the Error Rate block source.
>>>>>  I have never used this block, but in my thinking about it in this
>>>>> flowchart, I would source it from the throttle instead of the random
>>>>> source.  This may help with keeping the data a little more somewhat 
>>>>> aligned.
>>>>>
>>>>>
>>>> *Yes, this could make things clearer. But maybe it makes no difference.
>>>> I remember in one of Tom's tutorial, he said as long as there is one
>>>> throttle in the flow, then all the units are throttled.*
>>>>
>>>>>
>>>>>
>>>>> Michael
>>>>>
>>>>>
>>>>> On Wed, Dec 4, 2013 at 9:52 AM, Henry Jin <henry.ji...@gmail.com>wrote:
>>>>>
>>>>>> I tried again replacing the DPSK module with PSK module. Still cannot
>>>>>> get the correct data. The parameter for Error Rate "Bits per Symbol" is
>>>>>> changed to 8 since every bit carries information in my flow. The sizes of
>>>>>> the files from the two file sinks are exactly the same, except with
>>>>>> different data.
>>>>>>
>>>>>>
>>>>>> On Tue, Dec 3, 2013 at 10:11 PM, Nick Foster <bistrom...@gmail.com>wrote:
>>>>>>
>>>>>>> Can you try using the PSK mod/demod blocks with differential=Yes
>>>>>>> instead of the DPSK mod/demod blocks? I found an issue today with the 
>>>>>>> DPSK
>>>>>>> mod/demod blocks which results in them not actually using differential
>>>>>>> encoding.
>>>>>>>
>>>>>>> --n
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Dec 3, 2013 at 9:00 PM, Henry Jin <henry.ji...@gmail.com>wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I tried to build a simple flow graph of DPSK modulation and
>>>>>>>> demodulation. The result is verified using the Error Rate module. The 
>>>>>>>> link
>>>>>>>> shows the flow I'm using.
>>>>>>>>
>>>>>>>>
>>>>>>>> https://www.dropbox.com/s/jwmmttyi4es4alf/Screenshot%20from%202013-12-03%2021%3A50%3A58.png
>>>>>>>>
>>>>>>>> I know that the output of demod module is unpacked bytes, so an
>>>>>>>> "unpacked to packed" module is attached after demodulation. However, 
>>>>>>>> the
>>>>>>>> BER is close to 50%, which surely indicates something wrong. I further
>>>>>>>> analyzed the two inputs of the Error Rate module by writing info to the
>>>>>>>> file sink. It clearly shows the discrepancy. So I just wonder what is 
>>>>>>>> wrong
>>>>>>>> with this flow graph. Could someone please help me?
>>>>>>>>
>>>>>>>> Also, as I noticed, in the output file generated after "unpacked to
>>>>>>>> packed" module, there are many consecutive 0s at the start of the file.
>>>>>>>> Does that indicate something?
>>>>>>>>
>>>>>>>>  Suggestions are greatly appreciated!
>>>>>>>>
>>>>>>>> Henry
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
> _______________________________________________
> 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

Reply via email to