Hi all, I managed to find out the reason why error rate module cannot work. Just want to share my thoughts and hopefully it can help other guys when they want to do similar simulation.
As cited in my previous post below, I tried to evaluate the BER performance using GRC for DPSK modulation and demodulation. I made a mistake in this flowgraph since there is no synchronization module. So, we have to add some training sequence to the stream sent and do a correlation after the demodulation. In this way, the streams can be synchronized and the bit error rate can be correctly calculated. Of course, since we have to add some customized modules, the best way is to directly work on the python script. Best Henry On Tue, Dec 3, 2013 at 10: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! > On Sat, Dec 14, 2013 at 5:50 PM, Wayne Roberts <wroberts92...@gmail.com>wrote: > There isnt any QA code for QAM modulator or demodulator. > They do not work for me. > I think if they worked, then their would be QA code. > > > On Sat, Dec 14, 2013 at 12:08 PM, Henry Jin <henry.ji...@gmail.com> wrote: > >> Hi Wayne >> >> I agree with every point you mentioned in your reply. For the variable >> Bits per symbol, that was a mistake since I previously used it to test QAM. >> >> So, have you tested QAM? In my test, the two files didn't match as >> discussed in my previous post. Just curious about why this mismatch can >> happen. Thanks. >> >> Have a good weekend >> Henry >> >> >> On Sat, Dec 14, 2013 at 11:19 AM, Wayne Roberts >> <wroberts92...@gmail.com>wrote: >> >>> 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