Re: [Discuss-gnuradio] how to implement auto-correction of sample rate in flow graph ?
Hi Marcus, Everything you said I'm already thought about during last days and finally came to conclusion, that buffer estimation model is the only reliable (it solves issue directly by its nature) and universal one (many drivers provide required functions in their API). Since it involves control loop (i.e. have feedback), it will compensate all factors you mentioned on large time scales. Of course, its parameters should be tuned to given system to maintain it in stable state, at least. No matter, how many intermediate buffers exists between hardware source endpoint and hardware sink endpoint (including GR scheduler ones) and how they handled by system. All of them linked in one chain. Ideally we should combine all of them in single one large buffer and estimate its filling to get almost precise results (influenced by jitter only). In practice, software API allows estimate only some of them, but this is not problem. It just adds unknown offset of "buffer fallthrough" appearing at start-up (after source block prebuffered 50% and started streaming). Control loop will detect sudden underrun and will start injecting additional samples in data stream. Finally these "unknown" buffers will be filled up and system achieve stable state (finish of start-up phase). How long it will take ? Depends on these buffers sizes and filter coefficient of control loop algorithm. It's also possible to tune it with user-defined parameters (filter coefficient and "buffer offset") to get fastest start-up at given system. Sylvain Munaut-2 wrote > Now a real world vocoder I'm working with right now deals with this > problem by having variable length audio frames. When I get one frame > of encoded audio, I can ask the codec to generate between 19.5 ms to > 20.5 ms of audio (for a nominal 20ms frame) and it's of course much > better than dropping/repeating samples blindly. Hi, Agree, but it's not critical now. Since these corrections expected to be infrequent, they will not break signal very much. (In audio signal they even aren't audible to human ear.) I'm going to get system to work first, leaving tunings at very end. -- View this message in context: http://gnuradio.4.n7.nabble.com/how-to-implement-auto-correction-of-sample-rate-in-flow-graph-tp45268p45346.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] connection fails, No UHD Devices Found
It is very annoying that sometimes I can not connect to the device using this command: ~$ sudo ifconfig eth0 192.168.10.1 I can ping 192.168.10.1, but ping 192.168.10.2 fails: ~$ sudo ifconfig eth0 192.168.10.1 ~$ ping 192.168.10.2 PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data. From 192.168.10.1 icmp_seq=1 Destination Host Unreachable From 192.168.10.1 icmp_seq=2 Destination Host Unreachable From 192.168.10.1 icmp_seq=3 Destination Host Unreachable ~$ uhd_find_devices linux; GNU C++ version 4.7.3; Boost_104900; UHD_003.006.000-0-g7788c692 No UHD Devices Found --- Ubuntu 13.04, gnuradio 3.7, usrp N200 --- Why does it happen? How can I connect to USRP device? Thanks in advance! -- NE___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] connection fails, No UHD Devices Found
--- Ubuntu 13.04, gnuradio 3.7, usrp N200 --- It is very annoying that sometimes I can not connect to the device using this command: ~$ sudo ifconfig eth0 192.168.10.1 I can ping 192.168.10.1, but ping 192.168.10.2 fails: ~$ sudo ifconfig eth0 192.168.10.1 ~$ ping 192.168.10.2 PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data. From 192.168.10.1 icmp_seq=1 Destination Host Unreachable From 192.168.10.1 icmp_seq=2 Destination Host Unreachable From 192.168.10.1 icmp_seq=3 Destination Host Unreachable ~$ uhd_find_devices linux; GNU C++ version 4.7.3; Boost_104900; UHD_003.006.000-0-g7788c692 No UHD Devices Found Why does it happen? How can I connect to USRP device? Thanks in advance! -- NE -- -- NE ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] connection fails, No UHD Devices Found
On 12/14/2013 06:46 AM, Nasi wrote: --- Ubuntu 13.04, gnuradio 3.7, usrp N200 --- It is very annoying that sometimes I can not connect to the device using this command: ~$ sudo ifconfig eth0 192.168.10.1 I can ping 192.168.10.1, but ping 192.168.10.2 fails: ~$ sudo ifconfig eth0 192.168.10.1 ~$ ping 192.168.10.2 PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data. From 192.168.10.1 icmp_seq=1 Destination Host Unreachable From 192.168.10.1 icmp_seq=2 Destination Host Unreachable From 192.168.10.1 icmp_seq=3 Destination Host Unreachable ~$ uhd_find_devices linux; GNU C++ version 4.7.3; Boost_104900; UHD_003.006.000-0-g7788c692 No UHD Devices Found Why does it happen? How can I connect to USRP device? Thanks in advance! -- NE Most likely Network Manager is still thinking that your ethernet port is set for automatic address assignment via DHCP. YOu'll have to make sure that your system configuration is set for static. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] About DPSK mod and demod
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.hex2013-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..hS4:..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 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 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 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 wrote: >>> On Wed, Dec 4, 2013 at 12:13 PM, Michael Berman 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 ont
[Discuss-gnuradio] UHD and libusrp driver writing for RFX dpughterboards, RFX1900
Hi, I have an RFX1800 board with modifications allowing it to work in 900MHz and 1800MHz band. What I find annoying is that if I want to use it in both bands, each time I have to reprogram EEPROM. Life would be a lot easier if I had one driver that tunes the board in the whole freq range 750-2100MHz. I am aware of the fact that there has to be a gap between 1050-1500MHz, but what I really is to get rid of the EEPROM re-programming every time I want to use the div/2 bit. This would also be a good exercise for me on how to write a driver for a doughterboard. Can someone guide me which files I have to modify to have a "new" doughterboard driver using RFX1800 covering both high and low bands? I am interested in modifying old libusrp and new UHD drivers. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] About DPSK mod and demod
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 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.hex2013-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..hS4:..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 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 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 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 wrote: > On Wed, Dec 4, 2013 at 12:13 PM, Michael Berman > 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 > rea
Re: [Discuss-gnuradio] truble with the make part of gnuradio
Hey,
Thanks,
I have got that fixed.
Now I am using the 3.7.2.1
When it loads it display this :
Warning (from warnings module):
File
"C:\Python27\lib\site-packages\cheetah-2.4.4-py2.7.egg\Cheetah\Compiler.py",
line 1509
"\nYou don't have the C version of NameMapper installed! "
UserWarning:
You don't have the C version of NameMapper installed! I'm disabling
Cheetah's useStackFrames option as it is painfully slow with the Python
version of NameMapper. You should get a copy of Cheetah with the compiled C
version of NameMapper.
Warning: Block key "blocks_ctrlport_monitor_performance" not found when
loading category tree.
Warning: Block key "blocks_ctrlport_monitor_performance" not found when
loading category tree.
<<< Welcome to GNU Radio Companion 3.7.2.1 >>>
And then I open the dial_tone example to see if it's working o.k and I get:
Loading: "C:\Python27\gnuradio\share\gnuradio\examples\audio\dial_tone.grc"
>>> Error: Block key "variable_slider" not found in Platform - grc(GNU Radio
Companion)
Traceback (most recent call last):
File "C:\Python27\gnuradio\bin\gnuradio-companion.py", line 70, in
try:
gtk.window_set_default_icon(gtk.IconTheme().load_icon('gnuradio-grc', 256,
0))
GError: Icon 'gnuradio-grc' not present in theme
>>> Error: Block key "variable_slider" not found in Platform - grc(GNU Radio
Companion)
Traceback (most recent call last):
File "C:\Python27\gnuradio\bin\gnuradio-companion.py", line 70, in
try:
gtk.window_set_default_icon(gtk.IconTheme().load_icon('gnuradio-grc', 256,
0))
GError: Icon 'gnuradio-grc' not present in theme
>>> Done
Showing: "C:\Python27\gnuradio\share\gnuradio\examples\audio\dial_tone.grc"
It's not working + I can't add blocks.I see them on the side screen but when
I double click them nothing happen.
As I said before I am using:
I am using win7 64bit on a Lenovo i5
Gnuradio is 3.7.2.1 installed from pre compiled bin
Thank's,
iftah
From: iftah giladi [mailto:g_if...@yahoo.com]
Sent: Sunday, December 08, 2013 8:42 PM
To: 'discuss-gnuradio@gnu.org'
Subject: truble with the make part of gnuradio
Hey all,
I am using win7 64bit on a Lenovo i5.
Done all the Cygwin installation , got Cygwin64.
Then install all the packages needed.
Got the boost,
Got the wxPython
Got portaudio
And SDCC
And then I configure the gnuradio source for minimal using:
./configure --disable-all-components --enable-gruel --enable-gnuradio-core
--enable-gr-audio-oss
And then when I go for the make, I get error:
$ make
make all-recursive
make[1]: Entering directory '/usr/src/gnuradio-3.3.0'
Making all in config
make[2]: Entering directory '/usr/src/gnuradio-3.3.0/config'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/usr/src/gnuradio-3.3.0/config'
Making all in gruel
make[2]: Entering directory '/usr/src/gnuradio-3.3.0/gruel'
Making all in src
make[3]: Entering directory '/usr/src/gnuradio-3.3.0/gruel/src'
Making all in lib
make[4]: Entering directory '/usr/src/gnuradio-3.3.0/gruel/src/lib'
Making all in pmt
make[5]: Entering directory '/usr/src/gnuradio-3.3.0/gruel/src/lib/pmt'
make all-am
make[6]: Entering directory '/usr/src/gnuradio-3.3.0/gruel/src/lib/pmt'
make[6]: Nothing to be done for 'all-am'.
make[6]: Leaving directory '/usr/src/gnuradio-3.3.0/gruel/src/lib/pmt'
make[5]: Leaving directory '/usr/src/gnuradio-3.3.0/gruel/src/lib/pmt'
Making all in msg
make[5]: Entering directory '/usr/src/gnuradio-3.3.0/gruel/src/lib/msg'
make[5]: Nothing to be done for 'all'.
make[5]: Leaving directory '/usr/src/gnuradio-3.3.0/gruel/src/lib/msg'
make[5]: Entering directory '/usr/src/gnuradio-3.3.0/gruel/src/lib'
/bin/sh ../../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall
-Woverloaded-virtual-o test_gruel.
exe test_gruel.o pmt/libpmt-qa.la libgruel.la
libtool: link: g++ -g -O2 -Wall -Woverloaded-virtual -o .libs/test_gruel.exe
test_gruel.o pmt/.libs/libp
mt-qa.a -L/usr/lib -lcppunit -ldl ./.libs/libgruel.a -lboost_thread-mt
pmt/.libs/libpmt-qa.a(pmt.o): In function
`__static_initialization_and_destruction_0':
/usr/local/include/boost/system/error_code.hpp:222: undefined reference to
`boost::system::generic_catego
ry()'
/usr/local/include/boost/system/error_code.hpp:222:(.text.startup+0x12):
relocation truncated to fit: R_X
86_64_PC32 against undefined symbol `boost::system::generic_category()'
/usr/local/include/boost/system/error_code.hpp:223: undefined reference to
`boost::system::generic_catego
ry()'
/usr/local/include/boost/system/error_code.hpp:223:(.text.startup+0x1e):
relocation truncated to fit: R_X
86_64_PC32 against undefined symbol `boost::system::generic_category()'
/usr/local/include/boost/system/error_code.hpp:224: undefined reference to
`boost::system::system_categor
y()'
/usr/local/include/boost/system/error_code.hpp:224:(.text.startup+0x2a):
relocation truncated to fit: R_X
86_64_PC32 against undefined symbol `boost::system
[Discuss-gnuradio] gr-lte updated to GNU Radio 3.7 API
Hello GNU Radio enthusiasts, some time after the GNU Radio 3.7 release I started to move the code for 'gr-lte' to the new API. Besides moving it to the new API, I wanted to clean up code and rework a lot of tests. Thus, the whole transition took a lot of time and work. Now, all current blocks are moved to the GNU Radio 3.7 API with lots of enhancements. e.g. I tried to remove all hierarchical python blocks and created them as GRC hier blocks instead. Or runtime status events, like cell_id extraction, are all propagated through message ports now. Also, there is a PyBOMBS recipe now to ease the installation process. I hope 'gr-lte' can be useful for others. Source code is available at https://github.com/kit-cel/gr-lte Happy hacking Johannes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] About DPSK mod and demod
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 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 > 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.hex2013-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..hS4:..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 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 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 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 wrote: > >> On Wed, Dec 4, 2013 at 12:13 PM, Michael Berman > > 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. Yo
