Re: [Discuss-gnuradio] PyBOMBS install gnuradio 3.7.4
On Tue, May 20, 2014 at 11:06 AM, Activecat active...@gmail.com wrote: I've just reinstalled gnuradio yesterday, using PyBOMBS. The newly installed version is gnuradio 3.7.4. The installation succeeded, but it then failed to compile my custom module which worked flawlessly with previous gnuradio installation. The previous version was gnuradio 3.7.3 which was installed using build-gunuradio, which had no problem at all. Compilation error: Linking CXX shared library libgnuradio-activecat.so [ 71%] Built target gnuradio-activecat Scanning dependencies of target test-activecat [ 72%] Building CXX object lib/CMakeFiles/test-activecat.dir/test_activecat.cc.o [ 74%] Building CXX object lib/CMakeFiles/test-activecat.dir/qa_activecat.cc.o Linking CXX executable test-activecat /usr/bin/ld: CMakeFiles/test-activecat.dir/test_activecat.cc.o: undefined reference to symbol '_ZN5boost10filesystem6detail16create_directoryERKNS0_4pathEPNS_6system10error_codeE' /usr/bin/ld: note: '_ZN5boost10filesystem6detail16create_directoryERKNS0_4pathEPNS_6system10error_codeE' is defined in DSO /home/sgku/download/gnuradio/target/lib/libboost_filesystem-mt.so.1.53.0 so try adding it to the linker command line /home/sgku/download/gnuradio/target/lib/libboost_filesystem-mt.so.1.53.0: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status make[2]: *** [lib/test-activecat] Error 1 make[1]: *** [lib/CMakeFiles/test-activecat.dir/all] Error 2 make: *** [all] Error 2 The problem has been solved. Solution: Reinstall gnuradio using PyBOMBS, make sure prefix=/usr/local Note: During PyBOMBS install wizard, we are prompted for prefix, which defaults to ../target If we just press ENTER to accept the default value, then the prefix becomes something like /home/user1/download/gnuradio/target. But regardless of what has been configured for the prefix, the OOT (out-of-tree module) will be install into /usr/local. Since the newly generated setup_env.sh does not include /usr/local, above error could occur. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PyBOMBS install gnuradio 3.7.4
On 20.05.2014 09:58, Activecat wrote: Note: During PyBOMBS install wizard, we are prompted for prefix, which defaults to ../target If we just press ENTER to accept the default value, then the prefix becomes something like /home/user1/download/gnuradio/target. But regardless of what has been configured for the prefix, the OOT (out-of-tree module) will be install into /usr/local. Since the newly generated setup_env.sh does not include /usr/local, above error could occur. FYI, I don't like installing stuff to /usr/local. If you take PyBombs' directory, and then use -DCMAKE_INSTALL_PREFIX on your own OOT, that'll make both work and you don't have to screw around in your system's dirs. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Frame delay synchronization issue
On 19.05.2014 13:23, Irfan Ullah wrote: Hi all, I am using QPSK Mod and demod I have issue of how to synchronize my frame means how to remove delays from my received data in using GRC block my flow graph is attached with this mail. I am trying to use packet encoder and decoder for frame synchronization but it is not working with my mod and demod. Hey Irfan, I'm not sure phase is preserved in your flow graph. I recommend you start with a few components and slowly add things until you realize where the problem lies. Make use of the GUI sinks to check out signals and constellations. Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A question about function gr::block::set_history()
On 19.05.2014 17:48, Kun Qian wrote: Thank you for your quick answer! I think I get how gnuradio works with history from your slides: 1. When flowgraph starts, the read pointer of input buffer is set history()-1 items back. 2. After calling work()/general_work() function, gnuradio scheduler get the number of consumed items of that input buffer and move the read pointer forward by that number. Then scheduler wait until next time calling work()/general_work() function. Is it right? And I think I find the error. In gr::block::general_work(), the parameter ninput_items equals to the *sum* of *noutput_items of previous block* and *history()-1*, isn't it? I thought ninput_items equals to noutput_items of previous block when I built the block. That's right. Everything in the input buffer is described by ninput_items, and that includes history. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PyBOMBS install gnuradio 3.7.4
On Tue, May 20, 2014 at 4:29 PM, Martin Braun martin.br...@ettus.comwrote: FYI, I don't like installing stuff to /usr/local. If you take PyBombs' directory, and then use -DCMAKE_INSTALL_PREFIX on your own OOT, that'll make both work and you don't have to screw around in your system's dirs. M In this case we execute cmake -DCMAKE_INSTALL_PREFIX=/home/user1/download/gnuradio/target ../ in the OOT build directory. Is there any way to hard code this install_prefix into the OOT setting file, so that we just need cmake ../ in the OOT build directory? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PyBOMBS install gnuradio 3.7.4
On Tue, May 20, 2014 at 5:15 PM, Activecat active...@gmail.com wrote: In this case we execute cmake -DCMAKE_INSTALL_PREFIX=/home/user1/download/gnuradio/target ../ in the OOT build directory. Is there any way to hard code this install_prefix into the OOT setting file, so that we just need cmake ../ in the OOT build directory? Thanks, I've found the answer at http://www.cmake.org/pipermail/cmake/2007-September/016565.html ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] MIMO
Hello all: Recently the development of the MIMO has been the focus of intensive research.Any example codes about the MIMO(OFDM) to give someone like me a chance to get start? Thank you. Best regards ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Extra line in a module with python blocks
Hi there, I'm writing an OOT module. For now, the only block I've made is written in Python. I follow the guide and everythins is ok until I run the top_block and get this error: File /usr/local/lib/python2.7/dist-packages/mavlink/__init__.py, line 45, in module from mavlink_swig import * FYI, mavlink is the name of my module. Now, if I comment that line out everything seems to work fine. Is this a serious issue or can I just go on using it this way? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error building with new ZMQ
Yes, that's what the issue is: YA dependency! Thanks for your prompt feedback! I'll look into creating a cppzmq port, since one does not currently exist. We'll need to add CMake support for checking for this dependency, too. - MLD On May 19, 2014, at 10:39 PM, Ben Rosenbloom ben.rosenbl...@gmail.com wrote: I previously noticed that the gr-zeromq recipe needs to add dependency cppzmq which has been split out as its own project. https://github.com/zeromq/cppzmq ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Facebook
I hope the listserv will continue to also serve that purpose for those of us not entwined within the Facebook ecosystem (yes there are some of us out there) -matthew On May 20, 2014, at 1:05 AM, Mostafa Alizadeh m.alizade...@gmail.com wrote: Hi everybody, To be more communicative, we'v designed a page of GNURadio on facebook https://www.facebook.com/gnuradiodeveloper This page specially is for GNURadio developers who are following GNURadio ecosystem: ✔ new releases of GNURadio, ✔ new products of GNURadio, ✔ GNURadio conferences and events, ✔ new GNURadio-related projects and anything else related to GNURadio. We're looking for administrators for helping us on this page. Every volunteer Mail me. best, Mostafa ___ 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
Re: [Discuss-gnuradio] Facebook
On Tue, May 20, 2014 at 9:05 AM, Matthew Biederman m...@mbiederman.comwrote: I hope the listserv will continue to also serve that purpose for those of us not entwined within the Facebook ecosystem (yes there are some of us out there) -matthew Matthew, Please read Martin's response. The facebook page, while potentially useful, is not an official part of GNU Radio. The core dev team doesn't spend much time with any of the other services out there with GNU Radio pages/communities since we try not to fracture the location of questions and answers. They might each serve a separate purpose for the interest of community building in different niches of the Internet, but we are focused on this mailing list, gnuradio.org, and our github repo for gnuradio.git. Tom On May 20, 2014, at 1:05 AM, Mostafa Alizadeh m.alizade...@gmail.com wrote: Hi everybody, To be more communicative, we'v designed a page of GNURadio on facebook https://www.facebook.com/gnuradiodeveloper This page specially is for GNURadio developers who are following GNURadio ecosystem: ✔ new releases of GNURadio, ✔ new products of GNURadio, ✔ GNURadio conferences and events, ✔ new GNURadio-related projects and anything else related to GNURadio. We're looking for administrators for helping us on this page. Every volunteer Mail me. best, Mostafa ___ 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
Re: [Discuss-gnuradio] Extra line in a module with python blocks
On Tue, May 20, 2014 at 8:26 AM, Michal Jakubiak meho...@gmail.com wrote: Hi there, I'm writing an OOT module. For now, the only block I've made is written in Python. I follow the guide and everythins is ok until I run the top_block and get this error: File /usr/local/lib/python2.7/dist-packages/mavlink/__init__.py, line 45, in module from mavlink_swig import * FYI, mavlink is the name of my module. Now, if I comment that line out everything seems to work fine. Is this a serious issue or can I just go on using it this way? I believe this issue has been corrected in recent weeks (Marcus Mueller I think handled it for us). No, if you just have Python blocks, then you do not require the from xxx_swig import * line, so you should be fine. Just remember that you've done this if you ever add a C++ block to your project. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Frame delay synchronization issue
On Tue, May 20, 2014 at 5:06 AM, Martin Braun martin.br...@ettus.comwrote: On 19.05.2014 13:23, Irfan Ullah wrote: Hi all, I am using QPSK Mod and demod I have issue of how to synchronize my frame means how to remove delays from my received data in using GRC block my flow graph is attached with this mail. I am trying to use packet encoder and decoder for frame synchronization but it is not working with my mod and demod. Hey Irfan, I'm not sure phase is preserved in your flow graph. I recommend you start with a few components and slowly add things until you realize where the problem lies. Make use of the GUI sinks to check out signals and constellations. Martin Indeed. One of the reasons we often use differential encoding. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Facebook
On Tue, May 20, 2014 at 9:11 AM, Tom Rondeau t...@trondeau.com wrote: On Tue, May 20, 2014 at 9:05 AM, Matthew Biederman m...@mbiederman.comwrote: I hope the listserv will continue to also serve that purpose for those of us not entwined within the Facebook ecosystem (yes there are some of us out there) -matthew Matthew, Please read Martin's response. The facebook page, while potentially useful, is not an official part of GNU Radio. The core dev team doesn't spend much time with any of the other services out there with GNU Radio pages/communities since we try not to fracture the location of questions and answers. They might each serve a separate purpose for the interest of community building in different niches of the Internet, but we are focused on this mailing list, gnuradio.org, and our github repo for gnuradio.git. Tom Apologies. Martin wrote to just a few of us and not on the mailing list. We'll probably have more about this later, but rest assured that the we are not planning on moving attention away from the mailing list. Tom On May 20, 2014, at 1:05 AM, Mostafa Alizadeh m.alizade...@gmail.com wrote: Hi everybody, To be more communicative, we'v designed a page of GNURadio on facebook https://www.facebook.com/gnuradiodeveloper This page specially is for GNURadio developers who are following GNURadio ecosystem: ✔ new releases of GNURadio, ✔ new products of GNURadio, ✔ GNURadio conferences and events, ✔ new GNURadio-related projects and anything else related to GNURadio. We're looking for administrators for helping us on this page. Every volunteer Mail me. best, Mostafa ___ 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
Re: [Discuss-gnuradio] Facebook
Hey Mostafa, I'm always happy to see people participating in this community, and trying to add to its value. Without volunteers, we'd be pretty useless. Still, I have to add a couple of things to this: * We used to have a Facebook group, which was taken down due to lack of interest. It seems not many people in this community are active on Facebook, or don't even have accounts. * For most communication, we try and focus things on the mailing list and IRC (each suits a different purpose). We also have the G+ group, but we've made it very clear on the group page that this is mainly for dev call hangouts etc., and technical questions should be asked here. The same goes for the LinkedIn group, which has some discussions, but mostly promotions and none of the core members of this group participate there (and don't really want to, at least in the near future). There's also a very inactive subreddit. I would appreciate it if you added such a disclaimer to your group, since people might expect answers to questions they post, and then will be disappointed. * As a team of GNU Radio core developers, we already have trouble keeping our own page up to date. You are currently alone in managing a Facebook page, which means you'll have a lot of work with adding infos about releases, events etc... * By calling the account GNU Radio and using the official logo, you are creating a page that looks very much like it *is* an official project page. I do wish you would have contacted me beforehand, so we could have discussed this. * A page like this must be maintained and polished, a badly maintained page will do more damage than it'll help. There's a couple of questions that we need to sort out: - Are you certain you can handle the workload? - Is there really any interest in a Facebook group? Personally, I'm not convinced a Facebook group will help us in any way, but I'm open to a conversation. Martin On 20.05.2014 07:05, Mostafa Alizadeh wrote: Hi everybody, To be more communicative, we'v designed a page of GNURadio on facebook https://www.facebook.com/gnuradiodeveloper This page specially is for GNURadio developers who are following GNURadio ecosystem: ✔ new releases of GNURadio, ✔ new products of GNURadio, ✔ GNURadio conferences and events, ✔ new GNURadio-related projects and anything else related to GNURadio. We're looking for administrators for helping us on this page. Every volunteer Mail me. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Facebook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, as a single, small, sometimes lost, developer, I ask you: please don't open side channels on your own. A lot of us have been around this mailing list for a very long time, and we try to keep information as concentrated as possible. Already now we see a lot of people following tutorials from more-or-less dubious, most of the time totally outdated websites. We should really try to keep gnuradio.org the official page for all information on GNU Radio. I don't see why anyone of the official core team should try to update a facebook page with release info etc, if there is no question that this information can and should be found in gnuradio.org; I think you might have gone a little to far promising constant updates. Also, there's a lively community around GNU Radio, and things like conference announcements never go unnoticed on the discuss-gnuradio mailing list, so I really don't see the demand for a more communicative platform. In fact, the mailing list, the #gnuradio on freenode, the github page, the gnuradio.org wiki and of course the regular hangouts as much as conferences and hackfests are so much communication that it actually amounts to a fair amount of work to keep up with all the information exchanged. All in all, facebook is really a terrible platform for discussion if you want to make information well-searchable, well documented, self-organized; the average time until a post on the mailing list goes answered is in the order of hours; as a lot of the community earns its money with software radio related occupations, I doubt the frequency of qualified answers on facebook would ever be as high as on the mailing list. Greetings, Marcus On 20.05.2014 07:05, Mostafa Alizadeh wrote: Hi everybody, To be more communicative, we'v designed a page of GNURadio on facebook https://www.facebook.com/gnuradiodeveloper This page specially is for GNURadio developers who are following GNURadio ecosystem: ? new releases of GNURadio, ? new products of GNURadio, ? GNURadio conferences and events, ? new GNURadio-related projects and anything else related to GNURadio. We're looking for administrators for helping us on this page. Every volunteer Mail me. best, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTe1hDAAoJEBQ6EdjyzlHtT5QH/1x9pBE7tQS8qBj2pSK9zyPk ktT0iCPA40lSrMsyvzjl1+JKsS8X4p9W79PQyFGtRf42g5wTjUSr0XeGGJLIZcoZ r4asiV0GFc68bbnXMVkrUYkq46wXcrm/lT66rdKbb6WgVy6SyAllyXFVHmO6/xS7 uU/k0aGO5izYlDNPNDyXjgiZ54Qpj6ySXADLaKa7tbSRkfRsUktUv/zXaNehHHGV wSn4QlCHNXUQkN09ARgTyGIQlfWnolO++ENTjeqfKQKvJrN5BtgcELPY+N+Xq4zs DACuK9VooXYtm5TQDJ3K4fObe53bziM6gGkQU1dCEcEoTklF4SRM9+37Q+ZGhDU= =r6Yx -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] [Volk WG] Meeting Tuesday June 3
Hi all, Mark your calendars if you're interested in joining a call to discuss VOLK-things. Agenda is in the works. Date: Tuesday June 3 @ 1PM EST; 5PM UTC. Nathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Extra line in a module with python blocks
Hi Tom, hi Michael, jep, fixed that, and my pull request was recently merged (thanks, jcorgan ;) ). Sadly, the fix only applies to new modules, but the fix is basically the same as commenting that line out. Instead of commenting it out, you can be safe that your module will also respect C++ blocks if you add some later, you can try-except-surround that import statement like: try: from mavlink_swig import * except ImportError as e: pass (compare [1]) Greetings, Marcus [1] https://github.com/marcusmueller/gnuradio/commit/06023871a7966101a5e50d4d906628ecaecf94f0 On 20.05.2014 15:13, Tom Rondeau wrote: On Tue, May 20, 2014 at 8:26 AM, Michal Jakubiak meho...@gmail.com wrote: Hi there, I'm writing an OOT module. For now, the only block I've made is written in Python. I follow the guide and everythins is ok until I run the top_block and get this error: File /usr/local/lib/python2.7/dist-packages/mavlink/__init__.py, line 45, in module from mavlink_swig import * FYI, mavlink is the name of my module. Now, if I comment that line out everything seems to work fine. Is this a serious issue or can I just go on using it this way? I believe this issue has been corrected in recent weeks (Marcus Mueller I think handled it for us). No, if you just have Python blocks, then you do not require the from xxx_swig import * line, so you should be fine. Just remember that you've done this if you ever add a C++ block to your project. Tom ___ 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
Re: [Discuss-gnuradio] Random number of output items
Thanks Activecat you actually answered quite well to my question. I thought it might be better to send 0s, i'm glad you confirmed that. And thanks for the output algorithm. Could you tell me more about forecast? Most of the time I need 8 input samples to produce one byte output so I set the forecast like so: ninput_items_required[0] = noutput_items*8; It seems pretty straight forward. Is this correct? On Mon, May 19, 2014 at 9:32 PM, Activecat active...@gmail.com wrote: On Tue, May 20, 2014 at 2:17 AM, Francois Gervais francoisgerv...@gmail.com wrote: Hi, I'm making a block which takes bit from a bit slicer and output packets as input comes in. My block will output bytes so it can emulate a usb adapter that receives the RF signal and output a packet stream through an FTDI. That way I can use the stack that comes with the adapter without owning one. I'll use a FIFO file so other than not issuing the serail configuration the stack should be used pretty much as is. However, I'm not sure what I should do about the the number of outputs. Let say I'm waiting for the preamble, I won't output anything. When I get the preamble and the sync I'll send a sync byte of my own. From here every 8 inputs I'll output a byte. So basically my block will output 0 or 1 output. Can someone help me a little with the use of forecast and noutput_items in my case? Also do I need to use the consume_each function? If your block emulates a USB adapter, defines it as a source block, then you don't need to touch forecast(). If your block takes input from another block, then it is not source block. I don't really understand your requirements. The number of outputs (referred as noutput_items) is determined by the scheduler, not yourself. Says, when you have X bytes to send out, if X noutput_items: Send out noutput_items number of output, and return noutput_items if X noutput_items: Send out X number of output, and return X if X == noutput_items: (either one of above) When you send out a sync byte, add that to the output count. When you are waiting for the preamble, you may want to send out a series of zeros, rather than just producing no output. Producing no output may cause the downstream blocks to become unresponsive. ___ 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
Re: [Discuss-gnuradio] [Volk WG] Meeting Tuesday June 3
On 20.05.2014 15:36, West, Nathan wrote: Hi all, Mark your calendars if you're interested in joining a call to discuss VOLK-things. Agenda is in the works. Date: Tuesday June 3 @ 1PM EST; 5PM UTC. I've added this to our G+ page, if you click join it'll do the tz math and add it your calendar. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Random number of output items
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Francois, as Activecat, I'm kind of having a hard time understanidng your requirements. If you're emulating a hardware signal source, go for the source approach. If you're basically taking input from anywhere and packing it into packets of varying length, that's exactly what the PDU block infrastructure is for: http://gnuradio.org/doc/doxygen/page_tagged_stream_blocks.html Greetings, Marcus On 20.05.2014 15:59, Francois Gervais wrote: Thanks Activecat you actually answered quite well to my question. I thought it might be better to send 0s, i'm glad you confirmed that. And thanks for the output algorithm. Could you tell me more about forecast? Most of the time I need 8 input samples to produce one byte output so I set the forecast like so: ninput_items_required[0] = noutput_items*8; It seems pretty straight forward. Is this correct? On Mon, May 19, 2014 at 9:32 PM, Activecat active...@gmail.com wrote: On Tue, May 20, 2014 at 2:17 AM, Francois Gervais francoisgerv...@gmail.com wrote: Hi, I'm making a block which takes bit from a bit slicer and output packets as input comes in. My block will output bytes so it can emulate a usb adapter that receives the RF signal and output a packet stream through an FTDI. That way I can use the stack that comes with the adapter without owning one. I'll use a FIFO file so other than not issuing the serail configuration the stack should be used pretty much as is. However, I'm not sure what I should do about the the number of outputs. Let say I'm waiting for the preamble, I won't output anything. When I get the preamble and the sync I'll send a sync byte of my own. From here every 8 inputs I'll output a byte. So basically my block will output 0 or 1 output. Can someone help me a little with the use of forecast and noutput_items in my case? Also do I need to use the consume_each function? If your block emulates a USB adapter, defines it as a source block, then you don't need to touch forecast(). If your block takes input from another block, then it is not source block. I don't really understand your requirements. The number of outputs (referred as noutput_items) is determined by the scheduler, not yourself. Says, when you have X bytes to send out, if X noutput_items: Send out noutput_items number of output, and return noutput_items if X noutput_items: Send out X number of output, and return X if X == noutput_items: (either one of above) When you send out a sync byte, add that to the output count. When you are waiting for the preamble, you may want to send out a series of zeros, rather than just producing no output. Producing no output may cause the downstream blocks to become unresponsive. ___ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTe2FKAAoJEBQ6EdjyzlHtrvsH/3EhTVbESphbUfNeWmZe/rNU YYOVD7XVYVndHzstznIwvYlNVRLugjJw74pPJ0DS050b1ggc9mDK/mW4975BICau hQQktHxN3QReWk5qKwpAx6Y/+3bVpC+phyFzZO0+1TBwHNYexsVA+Zw0mkGrOuvA 3pInPREkJxqxcMrbZZhMTYVVDfOpB5MEjxHSKOMWyAQqop2fg1ahlEwpKjVqDmmV 9NhjSbIy29kpayTcEq525ha0QPMb5bRkRiP1sw4GqHDJZSHyUR4RWYYHiVfD3CvP /Bmx74UyS69gnP6NmMxun3OjWngpNHkJNC0lN/GGHVhz7YjwVXINuXNkbYuEVaM= =x2qL -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Random number of output items
Sorry about that I'll try to clarify thing. I'm using an rtl-sdr adapter to receive an RF signal. I demodulate it and send it through the MM clock recovery and bit slicer. Then the binary signal enters the block I'm talking about here. This block find a valid packet by matching the preamble and the sync pattern and translates the packet into another format that is understood by a software stack designed for these type of packets. Normally this stack would take it's input from a serial port but in my case I output the packets in the correct serial protocol through a file sink that is binded to a FIFO. I'll take a look at the PDU block but this translation needs to be done between two very specific protocol. I don't think a generic block can achieve that. Right now the development is mostly finished. All I need to make sure is that my block interface correctly with the scheduler since I don't have a fixed input to output number relationship. It's mostly 8:1 but that not always exactly the case. Hope it makes sense. On Tue, May 20, 2014 at 10:06 AM, Marcus Müller mar...@hostalia.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Francois, as Activecat, I'm kind of having a hard time understanidng your requirements. If you're emulating a hardware signal source, go for the source approach. If you're basically taking input from anywhere and packing it into packets of varying length, that's exactly what the PDU block infrastructure is for: http://gnuradio.org/doc/doxygen/page_tagged_stream_blocks.html Greetings, Marcus On 20.05.2014 15:59, Francois Gervais wrote: Thanks Activecat you actually answered quite well to my question. I thought it might be better to send 0s, i'm glad you confirmed that. And thanks for the output algorithm. Could you tell me more about forecast? Most of the time I need 8 input samples to produce one byte output so I set the forecast like so: ninput_items_required[0] = noutput_items*8; It seems pretty straight forward. Is this correct? On Mon, May 19, 2014 at 9:32 PM, Activecat active...@gmail.com wrote: On Tue, May 20, 2014 at 2:17 AM, Francois Gervais francoisgerv...@gmail.com wrote: Hi, I'm making a block which takes bit from a bit slicer and output packets as input comes in. My block will output bytes so it can emulate a usb adapter that receives the RF signal and output a packet stream through an FTDI. That way I can use the stack that comes with the adapter without owning one. I'll use a FIFO file so other than not issuing the serail configuration the stack should be used pretty much as is. However, I'm not sure what I should do about the the number of outputs. Let say I'm waiting for the preamble, I won't output anything. When I get the preamble and the sync I'll send a sync byte of my own. From here every 8 inputs I'll output a byte. So basically my block will output 0 or 1 output. Can someone help me a little with the use of forecast and noutput_items in my case? Also do I need to use the consume_each function? If your block emulates a USB adapter, defines it as a source block, then you don't need to touch forecast(). If your block takes input from another block, then it is not source block. I don't really understand your requirements. The number of outputs (referred as noutput_items) is determined by the scheduler, not yourself. Says, when you have X bytes to send out, if X noutput_items: Send out noutput_items number of output, and return noutput_items if X noutput_items: Send out X number of output, and return X if X == noutput_items: (either one of above) When you send out a sync byte, add that to the output count. When you are waiting for the preamble, you may want to send out a series of zeros, rather than just producing no output. Producing no output may cause the downstream blocks to become unresponsive. ___ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTe2FKAAoJEBQ6EdjyzlHtrvsH/3EhTVbESphbUfNeWmZe/rNU YYOVD7XVYVndHzstznIwvYlNVRLugjJw74pPJ0DS050b1ggc9mDK/mW4975BICau hQQktHxN3QReWk5qKwpAx6Y/+3bVpC+phyFzZO0+1TBwHNYexsVA+Zw0mkGrOuvA 3pInPREkJxqxcMrbZZhMTYVVDfOpB5MEjxHSKOMWyAQqop2fg1ahlEwpKjVqDmmV 9NhjSbIy29kpayTcEq525ha0QPMb5bRkRiP1sw4GqHDJZSHyUR4RWYYHiVfD3CvP /Bmx74UyS69gnP6NmMxun3OjWngpNHkJNC0lN/GGHVhz7YjwVXINuXNkbYuEVaM= =x2qL -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org
Re: [Discuss-gnuradio] Random number of output items
Hi, PDU blocks are a *type* of blocks. Basically, you tag your sample stream so that the blocks downstream know how long your packet is. The tagged stream infrastructure is an innovation meant to simplify the design of blocks dealing with packetized data. Lool in the gr-digital/examples subfolder for how some implementations of that principle are used. Greetings, Marcus On Tue, May 20, 2014 at 4:23 PM, Francois Gervais francoisgerv...@gmail.com wrote: Sorry about that I'll try to clarify thing. I'm using an rtl-sdr adapter to receive an RF signal. I demodulate it and send it through the MM clock recovery and bit slicer. Then the binary signal enters the block I'm talking about here. This block find a valid packet by matching the preamble and the sync pattern and translates the packet into another format that is understood by a software stack designed for these type of packets. Normally this stack would take it's input from a serial port but in my case I output the packets in the correct serial protocol through a file sink that is binded to a FIFO. I'll take a look at the PDU block but this translation needs to be done between two very specific protocol. I don't think a generic block can achieve that. Right now the development is mostly finished. All I need to make sure is that my block interface correctly with the scheduler since I don't have a fixed input to output number relationship. It's mostly 8:1 but that not always exactly the case. Hope it makes sense. On Tue, May 20, 2014 at 10:06 AM, Marcus Müller mar...@hostalia.dewrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Francois, as Activecat, I'm kind of having a hard time understanidng your requirements. If you're emulating a hardware signal source, go for the source approach. If you're basically taking input from anywhere and packing it into packets of varying length, that's exactly what the PDU block infrastructure is for: http://gnuradio.org/doc/doxygen/page_tagged_stream_blocks.html Greetings, Marcus On 20.05.2014 15:59, Francois Gervais wrote: Thanks Activecat you actually answered quite well to my question. I thought it might be better to send 0s, i'm glad you confirmed that. And thanks for the output algorithm. Could you tell me more about forecast? Most of the time I need 8 input samples to produce one byte output so I set the forecast like so: ninput_items_required[0] = noutput_items*8; It seems pretty straight forward. Is this correct? On Mon, May 19, 2014 at 9:32 PM, Activecat active...@gmail.com wrote: On Tue, May 20, 2014 at 2:17 AM, Francois Gervais francoisgerv...@gmail.com wrote: Hi, I'm making a block which takes bit from a bit slicer and output packets as input comes in. My block will output bytes so it can emulate a usb adapter that receives the RF signal and output a packet stream through an FTDI. That way I can use the stack that comes with the adapter without owning one. I'll use a FIFO file so other than not issuing the serail configuration the stack should be used pretty much as is. However, I'm not sure what I should do about the the number of outputs. Let say I'm waiting for the preamble, I won't output anything. When I get the preamble and the sync I'll send a sync byte of my own. From here every 8 inputs I'll output a byte. So basically my block will output 0 or 1 output. Can someone help me a little with the use of forecast and noutput_items in my case? Also do I need to use the consume_each function? If your block emulates a USB adapter, defines it as a source block, then you don't need to touch forecast(). If your block takes input from another block, then it is not source block. I don't really understand your requirements. The number of outputs (referred as noutput_items) is determined by the scheduler, not yourself. Says, when you have X bytes to send out, if X noutput_items: Send out noutput_items number of output, and return noutput_items if X noutput_items: Send out X number of output, and return X if X == noutput_items: (either one of above) When you send out a sync byte, add that to the output count. When you are waiting for the preamble, you may want to send out a series of zeros, rather than just producing no output. Producing no output may cause the downstream blocks to become unresponsive. ___ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTe2FKAAoJEBQ6EdjyzlHtrvsH/3EhTVbESphbUfNeWmZe/rNU
Re: [Discuss-gnuradio] Random number of output items
Thanks I'll take a closer look. On Tue, May 20, 2014 at 10:34 AM, Marcus Müller marcus.muel...@ettus.comwrote: Hi, PDU blocks are a *type* of blocks. Basically, you tag your sample stream so that the blocks downstream know how long your packet is. The tagged stream infrastructure is an innovation meant to simplify the design of blocks dealing with packetized data. Lool in the gr-digital/examples subfolder for how some implementations of that principle are used. Greetings, Marcus On Tue, May 20, 2014 at 4:23 PM, Francois Gervais francoisgerv...@gmail.com wrote: Sorry about that I'll try to clarify thing. I'm using an rtl-sdr adapter to receive an RF signal. I demodulate it and send it through the MM clock recovery and bit slicer. Then the binary signal enters the block I'm talking about here. This block find a valid packet by matching the preamble and the sync pattern and translates the packet into another format that is understood by a software stack designed for these type of packets. Normally this stack would take it's input from a serial port but in my case I output the packets in the correct serial protocol through a file sink that is binded to a FIFO. I'll take a look at the PDU block but this translation needs to be done between two very specific protocol. I don't think a generic block can achieve that. Right now the development is mostly finished. All I need to make sure is that my block interface correctly with the scheduler since I don't have a fixed input to output number relationship. It's mostly 8:1 but that not always exactly the case. Hope it makes sense. On Tue, May 20, 2014 at 10:06 AM, Marcus Müller mar...@hostalia.dewrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Francois, as Activecat, I'm kind of having a hard time understanidng your requirements. If you're emulating a hardware signal source, go for the source approach. If you're basically taking input from anywhere and packing it into packets of varying length, that's exactly what the PDU block infrastructure is for: http://gnuradio.org/doc/doxygen/page_tagged_stream_blocks.html Greetings, Marcus On 20.05.2014 15:59, Francois Gervais wrote: Thanks Activecat you actually answered quite well to my question. I thought it might be better to send 0s, i'm glad you confirmed that. And thanks for the output algorithm. Could you tell me more about forecast? Most of the time I need 8 input samples to produce one byte output so I set the forecast like so: ninput_items_required[0] = noutput_items*8; It seems pretty straight forward. Is this correct? On Mon, May 19, 2014 at 9:32 PM, Activecat active...@gmail.com wrote: On Tue, May 20, 2014 at 2:17 AM, Francois Gervais francoisgerv...@gmail.com wrote: Hi, I'm making a block which takes bit from a bit slicer and output packets as input comes in. My block will output bytes so it can emulate a usb adapter that receives the RF signal and output a packet stream through an FTDI. That way I can use the stack that comes with the adapter without owning one. I'll use a FIFO file so other than not issuing the serail configuration the stack should be used pretty much as is. However, I'm not sure what I should do about the the number of outputs. Let say I'm waiting for the preamble, I won't output anything. When I get the preamble and the sync I'll send a sync byte of my own. From here every 8 inputs I'll output a byte. So basically my block will output 0 or 1 output. Can someone help me a little with the use of forecast and noutput_items in my case? Also do I need to use the consume_each function? If your block emulates a USB adapter, defines it as a source block, then you don't need to touch forecast(). If your block takes input from another block, then it is not source block. I don't really understand your requirements. The number of outputs (referred as noutput_items) is determined by the scheduler, not yourself. Says, when you have X bytes to send out, if X noutput_items: Send out noutput_items number of output, and return noutput_items if X noutput_items: Send out X number of output, and return X if X == noutput_items: (either one of above) When you send out a sync byte, add that to the output count. When you are waiting for the preamble, you may want to send out a series of zeros, rather than just producing no output. Producing no output may cause the downstream blocks to become unresponsive. ___ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with
[Discuss-gnuradio] Building error of GNURadio 3.7.2
Hi everyone, I've tried to build GNRadio 3.7.2.1 from source, when I came to make step I've received two strange error, you find hereafter what it looks like: *** [ 13%] Generating python docstrings for pmt_swig_doc Traceback (most recent call last): File /gnuradio-3.7.2/docs/doxygen/swig_doc.py, line 328, in module make_swig_interface_file(di, swigdocfilename, custom_output=custom_output) File /gnuradio-3.7.2/docs/doxygen/swig_doc.py, line 251, in make_swig_interface_file blocks = di.in_category(Block) File /gnuradio-3.7.2/docs/doxygen/doxyxml/base.py, line 140, in in_category self.confirm_no_error() File xx/gnuradio-3.7.2/docs/doxygen/doxyxml/base.py, line 206, in confirm_no_error self.check_parsed() File /gnuradio-3.7.2/docs/doxygen/doxyxml/base.py, line 203, in check_parsed self._parse() File /gnuradio-3.7.2/docs/doxygen/doxyxml/doxyindex.py, line 54, in _parse self._members += converted.members() File xxx/gnuradio-3.7.2/docs/doxygen/doxyxml/base.py, line 174, in members self.confirm_no_error() File xx/gnuradio-3.7.2/docs/doxygen/doxyxml/base.py, line 206, in confirm_no_error self.check_parsed() File xxx/gnuradio-3.7.2/docs/doxygen/doxyxml/base.py, line 203, in check_parsed self._parse() File xxx/gnuradio-3.7.2/docs/doxygen/doxyxml/doxyindex.py, line 238, in _parse self.retrieve_data() File xxx/gnuradio-3.7.2/docs/doxygen/doxyxml/base.py, line 193, in retrieve_data filename = os.path.join(self._xml_path, self.refid + '.xml') File /usr/lib64/python2.7/posixpath.py, line 80, in join path += '/' + b UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 17: ordinal not in range(128) make[2]: *** [gnuradio-runtime/swig/pmt_swig_doc.i] Erreur 1 make[1]: *** [gnuradio-runtime/swig/CMakeFiles/pmt_swig_swig_doc.dir/all] Erreur 2 make: *** [all] Erreur 2 Could someone help me fix this ? Thanks. -- View this message in context: http://gnuradio.4.n7.nabble.com/Building-error-of-GNURadio-3-7-2-tp48375.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
Re: [Discuss-gnuradio] Building error of GNURadio 3.7.2
On Tue, May 20, 2014 at 11:47 AM, mohamedx mohamed.abouz...@gmail.comwrote: Hi everyone, I've tried to build GNRadio 3.7.2.1 from source, when I came to make step I've received two strange error, you find hereafter what it looks like: *** [ 13%] Generating python docstrings for pmt_swig_doc Traceback (most recent call last): File /gnuradio-3.7.2/docs/doxygen/swig_doc.py, line 328, in module make_swig_interface_file(di, swigdocfilename, custom_output=custom_output) File /gnuradio-3.7.2/docs/doxygen/swig_doc.py, line 251, in make_swig_interface_file blocks = di.in_category(Block) File /gnuradio-3.7.2/docs/doxygen/doxyxml/base.py, line 140, in in_category self.confirm_no_error() File xx/gnuradio-3.7.2/docs/doxygen/doxyxml/base.py, line 206, in confirm_no_error self.check_parsed() File /gnuradio-3.7.2/docs/doxygen/doxyxml/base.py, line 203, in check_parsed self._parse() File /gnuradio-3.7.2/docs/doxygen/doxyxml/doxyindex.py, line 54, in _parse self._members += converted.members() File xxx/gnuradio-3.7.2/docs/doxygen/doxyxml/base.py, line 174, in members self.confirm_no_error() File xx/gnuradio-3.7.2/docs/doxygen/doxyxml/base.py, line 206, in confirm_no_error self.check_parsed() File xxx/gnuradio-3.7.2/docs/doxygen/doxyxml/base.py, line 203, in check_parsed self._parse() File xxx/gnuradio-3.7.2/docs/doxygen/doxyxml/doxyindex.py, line 238, in _parse self.retrieve_data() File xxx/gnuradio-3.7.2/docs/doxygen/doxyxml/base.py, line 193, in retrieve_data filename = os.path.join(self._xml_path, self.refid + '.xml') File /usr/lib64/python2.7/posixpath.py, line 80, in join path += '/' + b UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 17: ordinal not in range(128) make[2]: *** [gnuradio-runtime/swig/pmt_swig_doc.i] Erreur 1 make[1]: *** [gnuradio-runtime/swig/CMakeFiles/pmt_swig_swig_doc.dir/all] Erreur 2 make: *** [all] Erreur 2 Could someone help me fix this ? Thanks. Hmm, that's a new one. Wish it was more clear where the bug was coming from in the doc files. But instead of trying to debug it, just turn off the Doxygen build by passing cmake '-DENABLE_DOXYGEN=False' and then rebuild. You can always get to the manual here: http://gnuradio.org/doc/doxygen/ And for 3.7.2: http://gnuradio.org/doc/doxygen-3.7.2/ Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem with qt constellation block
On Mon, May 19, 2014 at 2:46 PM, zielalaoui z.i.elala...@gmail.com wrote: Hi All, I'm trying to built a system with several digital modulations. First, I should be able to print constellations by using qt constellation block. I started by creating a simple flowgraph with two modulations. That is my flowgraph http://gnuradio.4.n7.nabble.com/file/n48338/qt_applic.jpeg . I take the top_block.py file and I tried to modify it by adding new function to switch the null sink and the constellation block by using disconnect() and connect() function. finally in the main function i added lock() and unlock() functions to reconfigure the application. the problem is when i run the modified python file the constellation graphic appear but it conserves the first constellation representation even the switching is happened . what do you think about that? should I write something to rerun the qt application? I appreciate your help Yes, the QT sinks keep some internal buffers, which are preserved during a lock/unlock reset event. You could look to overload the start() function (add a bool cosnt_sink_c_impl::start() function) that calls just calls _reset() and returns block::start(). In the extreme, you could cal memset on all d_residbufs_real and d_residbufs_imag to rest them to 0, but I think just calling _reset and having the pointers appropriately update should be enough. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Random number of output items
Hi Marcus, I'm not sure about the steps required to translate the bit stream from the RF receiver into a tagged stream. I looked at the ofdm_rx example and from what I understand I'll need a first block that takes the output of the demod/Clock Recovery/bit slicer and find the packets inside the stream and tag it so the other blocks can work with the tagged stream. This first block is a normal one that inherit from the generic Block class it that it? Does this first block need to output anything while waiting for the preamble of a packet to prevent the downstream block from freezing? Once the stream is packetized and tagged it seems pretty straight forward. Thanks On Tue, May 20, 2014 at 10:37 AM, Francois Gervais francoisgerv...@gmail.com wrote: Thanks I'll take a closer look. On Tue, May 20, 2014 at 10:34 AM, Marcus Müller marcus.muel...@ettus.comwrote: Hi, PDU blocks are a *type* of blocks. Basically, you tag your sample stream so that the blocks downstream know how long your packet is. The tagged stream infrastructure is an innovation meant to simplify the design of blocks dealing with packetized data. Lool in the gr-digital/examples subfolder for how some implementations of that principle are used. Greetings, Marcus On Tue, May 20, 2014 at 4:23 PM, Francois Gervais francoisgerv...@gmail.com wrote: Sorry about that I'll try to clarify thing. I'm using an rtl-sdr adapter to receive an RF signal. I demodulate it and send it through the MM clock recovery and bit slicer. Then the binary signal enters the block I'm talking about here. This block find a valid packet by matching the preamble and the sync pattern and translates the packet into another format that is understood by a software stack designed for these type of packets. Normally this stack would take it's input from a serial port but in my case I output the packets in the correct serial protocol through a file sink that is binded to a FIFO. I'll take a look at the PDU block but this translation needs to be done between two very specific protocol. I don't think a generic block can achieve that. Right now the development is mostly finished. All I need to make sure is that my block interface correctly with the scheduler since I don't have a fixed input to output number relationship. It's mostly 8:1 but that not always exactly the case. Hope it makes sense. On Tue, May 20, 2014 at 10:06 AM, Marcus Müller mar...@hostalia.dewrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Francois, as Activecat, I'm kind of having a hard time understanidng your requirements. If you're emulating a hardware signal source, go for the source approach. If you're basically taking input from anywhere and packing it into packets of varying length, that's exactly what the PDU block infrastructure is for: http://gnuradio.org/doc/doxygen/page_tagged_stream_blocks.html Greetings, Marcus On 20.05.2014 15:59, Francois Gervais wrote: Thanks Activecat you actually answered quite well to my question. I thought it might be better to send 0s, i'm glad you confirmed that. And thanks for the output algorithm. Could you tell me more about forecast? Most of the time I need 8 input samples to produce one byte output so I set the forecast like so: ninput_items_required[0] = noutput_items*8; It seems pretty straight forward. Is this correct? On Mon, May 19, 2014 at 9:32 PM, Activecat active...@gmail.com wrote: On Tue, May 20, 2014 at 2:17 AM, Francois Gervais francoisgerv...@gmail.com wrote: Hi, I'm making a block which takes bit from a bit slicer and output packets as input comes in. My block will output bytes so it can emulate a usb adapter that receives the RF signal and output a packet stream through an FTDI. That way I can use the stack that comes with the adapter without owning one. I'll use a FIFO file so other than not issuing the serail configuration the stack should be used pretty much as is. However, I'm not sure what I should do about the the number of outputs. Let say I'm waiting for the preamble, I won't output anything. When I get the preamble and the sync I'll send a sync byte of my own. From here every 8 inputs I'll output a byte. So basically my block will output 0 or 1 output. Can someone help me a little with the use of forecast and noutput_items in my case? Also do I need to use the consume_each function? If your block emulates a USB adapter, defines it as a source block, then you don't need to touch forecast(). If your block takes input from another block, then it is not source block. I don't really understand your requirements. The number of outputs (referred as noutput_items) is determined by the scheduler, not yourself. Says, when you have X bytes to send out, if X noutput_items: Send out noutput_items number of output, and return noutput_items if X noutput_items: Send out X number of
Re: [Discuss-gnuradio] Facebook
Hi Martin, I must explain more about the page in order to avoid these questions. However, I'm gonna clarify. First of all, I didn't know you have similar page of GNURadio on Facebook before and I don't know why the people didn't pay attention to that. Secondly, I don't want to distract you from the mailing list, as you said there is the most attention. This is enough to have only one location for discussions and here is the best as I found. I just want to propagate GNURadio ideas and its news etc. (as a mean to attract more people). Thirdly, as you mentioned, I have to do much on this page to make it up to date from time to time. However, I may do not have enough time to do so. Currently I'm looking for someone to help me on this. Fourthly, I called the page GNURadio as it is. I also care about its verification. This is page isn't verified by Facebook. If it was verified by an original publisher, a sign of blue tick must be appeared next to the name of the page, take a look at ted page https://www.facebook.com/TED. I know if the page isn't designed carefully and interesting, it would harm the picture of GNURadio too. *For your questions:* # I just can decide on my status quo and now I can say that I handle the page but the future isn't deterministic for me. # I believe in that this page will absolutely attract more people to GNURadio. On Tue, May 20, 2014 at 5:57 PM, Marcus Müller mar...@hostalia.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, as a single, small, sometimes lost, developer, I ask you: please don't open side channels on your own. A lot of us have been around this mailing list for a very long time, and we try to keep information as concentrated as possible. Already now we see a lot of people following tutorials from more-or-less dubious, most of the time totally outdated websites. We should really try to keep gnuradio.org the official page for all information on GNU Radio. I don't see why anyone of the official core team should try to update a facebook page with release info etc, if there is no question that this information can and should be found in gnuradio.org; I think you might have gone a little to far promising constant updates. Also, there's a lively community around GNU Radio, and things like conference announcements never go unnoticed on the discuss-gnuradio mailing list, so I really don't see the demand for a more communicative platform. In fact, the mailing list, the #gnuradio on freenode, the github page, the gnuradio.org wiki and of course the regular hangouts as much as conferences and hackfests are so much communication that it actually amounts to a fair amount of work to keep up with all the information exchanged. All in all, facebook is really a terrible platform for discussion if you want to make information well-searchable, well documented, self-organized; the average time until a post on the mailing list goes answered is in the order of hours; as a lot of the community earns its money with software radio related occupations, I doubt the frequency of qualified answers on facebook would ever be as high as on the mailing list. Greetings, Marcus On 20.05.2014 07:05, Mostafa Alizadeh wrote: Hi everybody, To be more communicative, we'v designed a page of GNURadio on facebook https://www.facebook.com/gnuradiodeveloper This page specially is for GNURadio developers who are following GNURadio ecosystem: ? new releases of GNURadio, ? new products of GNURadio, ? GNURadio conferences and events, ? new GNURadio-related projects and anything else related to GNURadio. We're looking for administrators for helping us on this page. Every volunteer Mail me. best, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTe1hDAAoJEBQ6EdjyzlHtT5QH/1x9pBE7tQS8qBj2pSK9zyPk ktT0iCPA40lSrMsyvzjl1+JKsS8X4p9W79PQyFGtRf42g5wTjUSr0XeGGJLIZcoZ r4asiV0GFc68bbnXMVkrUYkq46wXcrm/lT66rdKbb6WgVy6SyAllyXFVHmO6/xS7 uU/k0aGO5izYlDNPNDyXjgiZ54Qpj6ySXADLaKa7tbSRkfRsUktUv/zXaNehHHGV wSn4QlCHNXUQkN09ARgTyGIQlfWnolO++ENTjeqfKQKvJrN5BtgcELPY+N+Xq4zs DACuK9VooXYtm5TQDJ3K4fObe53bziM6gGkQU1dCEcEoTklF4SRM9+37Q+ZGhDU= =r6Yx -END PGP SIGNATURE- ___ 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
Re: [Discuss-gnuradio] Facebook
I won't repeat what has already been written by others, but I will agree with them that my primary means of GR related help and discussion is this email list, IRC, and personal emails. My Facebook account is not used for work purposes, and I have no use for a work FB account; so, I won't be joining this group. That said, if others value this means for discussing GNU Radio then by all means proceed. -That- said, please make group postings public such that anybody in the group can cross-post to this email list and anybody can read the referred-to posting on FB without requiring a FB account. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Facebook
Hi dear Marcus, I didn't really want to move attention from here to other places! The GNURadio website didn't constructed informative. I mean any updates to the website do not appear for GNURadio followers. At least one of the Facebook advantages is its real-time interactions and communications. I'm not gonna compare this page with this mailing list, however, Facebook let more people engages in GNURadio. best, Mostafa On Tue, May 20, 2014 at 5:57 PM, Marcus Müller mar...@hostalia.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, as a single, small, sometimes lost, developer, I ask you: please don't open side channels on your own. A lot of us have been around this mailing list for a very long time, and we try to keep information as concentrated as possible. Already now we see a lot of people following tutorials from more-or-less dubious, most of the time totally outdated websites. We should really try to keep gnuradio.org the official page for all information on GNU Radio. I don't see why anyone of the official core team should try to update a facebook page with release info etc, if there is no question that this information can and should be found in gnuradio.org; I think you might have gone a little to far promising constant updates. Also, there's a lively community around GNU Radio, and things like conference announcements never go unnoticed on the discuss-gnuradio mailing list, so I really don't see the demand for a more communicative platform. In fact, the mailing list, the #gnuradio on freenode, the github page, the gnuradio.org wiki and of course the regular hangouts as much as conferences and hackfests are so much communication that it actually amounts to a fair amount of work to keep up with all the information exchanged. All in all, facebook is really a terrible platform for discussion if you want to make information well-searchable, well documented, self-organized; the average time until a post on the mailing list goes answered is in the order of hours; as a lot of the community earns its money with software radio related occupations, I doubt the frequency of qualified answers on facebook would ever be as high as on the mailing list. Greetings, Marcus On 20.05.2014 07:05, Mostafa Alizadeh wrote: Hi everybody, To be more communicative, we'v designed a page of GNURadio on facebook https://www.facebook.com/gnuradiodeveloper This page specially is for GNURadio developers who are following GNURadio ecosystem: ? new releases of GNURadio, ? new products of GNURadio, ? GNURadio conferences and events, ? new GNURadio-related projects and anything else related to GNURadio. We're looking for administrators for helping us on this page. Every volunteer Mail me. best, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTe1hDAAoJEBQ6EdjyzlHtT5QH/1x9pBE7tQS8qBj2pSK9zyPk ktT0iCPA40lSrMsyvzjl1+JKsS8X4p9W79PQyFGtRf42g5wTjUSr0XeGGJLIZcoZ r4asiV0GFc68bbnXMVkrUYkq46wXcrm/lT66rdKbb6WgVy6SyAllyXFVHmO6/xS7 uU/k0aGO5izYlDNPNDyXjgiZ54Qpj6ySXADLaKa7tbSRkfRsUktUv/zXaNehHHGV wSn4QlCHNXUQkN09ARgTyGIQlfWnolO++ENTjeqfKQKvJrN5BtgcELPY+N+Xq4zs DACuK9VooXYtm5TQDJ3K4fObe53bziM6gGkQU1dCEcEoTklF4SRM9+37Q+ZGhDU= =r6Yx -END PGP SIGNATURE- ___ 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] For Sale: USRP N210 w/daughterboards
Hi all, I'm selling my USRP N210 setup. Includes: Ettus USRP N210 BasicTX Daughterboard 1-250 MHz Tx. BasicRX Daughterboard 1-250 MHz Rx. LFRX Daughterboard 0-30 MHz Rx. WBX 50-2200 MHz Rx/Tx. XCVR2450 2.4-2.5 GHz, 4.9-5.9 GHz Tx/Rx. Power adapter. Additional bulk head cables. Cable for MIMO with another compatible device. I'm a hobbyist and the gear has never left my desk. All in excellent physical and working condition. $1900 for all. Please contact me off list via email if interested. Thanks, Dean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OutOfTree Module Tutorial
No, your version is not compatible. You can either change your version. Or, try the following change: In your code, instead of using /blocks.vector_source_f()/ use /gr.vector_source_f()/ Apply this change to both, the source as well as sink definition. HTH, Rishabh Dabral -- View this message in context: http://gnuradio.4.n7.nabble.com/OutOfTree-Module-Tutorial-tp45568p48384.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] Hierarchical Block Installation Source
This may be a dumb question but where do the custom hierarchical blocks generated in GRC get installed too? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Random number of output items
On Tue, May 20, 2014 at 10:23 PM, Francois Gervais francoisgerv...@gmail.com wrote: Sorry about that I'll try to clarify thing. I'm using an rtl-sdr adapter to receive an RF signal. I demodulate it and send it through the MM clock recovery and bit slicer. Then the binary signal enters the block I'm talking about here. This block find a valid packet by matching the preamble and the sync pattern and translates the packet into another format that is understood by a software stack designed for these type of packets. Normally this stack would take it's input from a serial port but in my case I output the packets in the correct serial protocol through a file sink that is binded to a FIFO. A picture is worth a thousand words. If you attached your existing flowgraph then it helps a lot. I'll take a look at the PDU block but this translation needs to be done between two very specific protocol. I don't think a generic block can achieve that. Please be reminded that PDU and tagged stream are two different things. There are PUD to Tagged Stream and also Tagged Stream to PDU blocks, to perform conversions. Tagged Stream Block is a special block that can only take input of tagged stream; the tag of the first element must consists the packet-length information, here the default tag key is packet_len PDU is used for Message Passing, I doubt you really need this in your flowgraph. If you are sure that your custom block needs to produce output in packets (not solely bytes), then you may want to make the block output as tagged stream. If applicable, in alternative, you may consider to use the Stream to Tagged Stream block. In this case, the downstream blocks may be inherited from Tagged Stream Block. In cases other than that, you don't need tagged stream block at all. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
