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
