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
