Re: [Discuss-gnuradio] gr_modtool makexml fails for block coded in python
On 01/19/2014 05:12 AM, Activecat wrote: Question: Does gr_modtool makexml work with block coded in python ? Dear Activecat, no, it doesn't. This is one project I'm currently working on, but I admit it's low-priority. MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using Header/Payload Demux
On 01/18/2014 09:46 PM, chris 0 wrote: Hi, I'm wondering if anyone can take a look at my grc file, which uses the header/payload demux to try to obtain a payload - but I'm currently getting incorrect values from the tags. For instance packet_len should be 10, but the value is mostly 1. I've attached the file. If you can't open it from the email i've also uploaded to - http://www.anfractuosity.com/files/mux2.grc Hey Chris, nice to see people using this block! Outside of the OFDM scope, it hasn't yet received too much attention. A couple of comments: - The CRC block increases the packet length by 4. This means packet_len *should* be 14. I ran the simulation, and that's what it was -- so it seems your code is working. However, the repacker thinks '14 bits', and will then produce 1 byte at the output (because floor(14/8)==1, and we have that 'floor' because the alignment is set to 'output'). That's why you see 1 item at the first tag debug. - In your setup, there is no mechanism that tells the receiver that '14' actually means '14 bytes', not '14 items'. The payload length is *actually* 14*8==112! This means the stream crc check block will never get the right data to work on. The latter problem is easy to fix in your case. Simply use a tagged_stream_multiply_length block after the demux, before the repacking. In the OFDM case, this is more complicated, because the number of OFDM symbols and the number of data symbols is not necessarily an integer multiple of one another. Here, a more elaborate solution is used: The packet header formatter object is inherited from and modified to produce both tags at the payload output. Apart from that, you're model is correct, and a good simple example for the demuxer! A hint for debugging: Use more tag debugs, with different names, not only at the rx path, but also on tx. This way, you can identify problems very quickly. MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [USRP-users] GNU radio error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Bhaskar, wrong list. I've included discuss-gnuradio to my reply, so that the people over there are aware. However, your problem description lacks several important answers. First of all, I can't remember there being a windows 2007; you mean windows 7, don't you? Have you installed it from a binary installer or built it yourself? Does any of the supplied examples work? Can you start a flowgraph containing a wxgui widget or instrumentation panel from the GNU Radio companion? Then: You must build GNU Radio with the wxgui submodule (or have a binary installer that includes that) to have wxgui available; I don't even know if wxgui is available under windows, so you should first verify that. Happy hacking, Marcus On 20.01.2014 10:32, BHASKAR BANERJEE wrote: Hi I installed GNU radio in windows 2007 but when I am executing a flow graph it is giving the following error Traceback (most recent call last): File D:\top_block.py, line 15, in module from grc_gnuradio import wxgui as grc_wxgui ImportError: cannot import name wxgui Why is this happening Thanks Bhaskar ___ USRP-users mailing list usrp-us...@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS3P8GAAoJEAFxB7BbsDrLUtAH/0UykCo5JTKTRrD6+w7AqDUB p7jIKxrBlwBV1/xWLejdAmYVDMGudYgLriOXpgSRgIlAymuI/Q50vECJDW5Y4wEx gf1hopvkCmiwMgbQieoxGI91YMqOBet4ApkSlok6xfzikztzphLqcFFT3ZxuyKSZ gvGd7V0n1DYJByr7+BpuxSFzEhnB6ZJrNhO07oOmhVD+7EkWUVNQU0XzeM5ruDKD vsU3f/zCnJfJ2opIdTb2zpF7yrf+awLykUKFtNCOF490egzGg4uoD14dNOWwyq9X IkYNbkpu3MAwU8AwVaa5aBAo9OVXDQwqpFf7hA9UM1Cv22fikpemZKprXWOCXzc= =E6TE -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-fcdproplus for OSX
I just made some changes to CMakelist files on gr-fcdproplus on github to hopefully run on OSX, now: hidmac.c and some IOKIT libs should be used if osx is detected, and the xml grc file now contains FUNcube Dongle V2.0 in the device string. On linux it remains empty and autodetection by looking into /proc/asound/cards is used. But as I have no access to OSX , I could not really test, so some problems my remain. If somebody could test, I would fix those problems. -- Volker ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-fcdproplus for OSX
Awesome; I'll try it out shortly. - MLD On Jan 20, 2014, at 6:52 AM, Volker Schroer dl1...@gmx.de wrote: I just made some changes to CMakelist files on gr-fcdproplus on github to hopefully run on OSX, now: hidmac.c and some IOKIT libs should be used if osx is detected, and the xml grc file now contains FUNcube Dongle V2.0 in the device string. On linux it remains empty and autodetection by looking into /proc/asound/cards is used. But as I have no access to OSX , I could not really test, so some problems my remain. If somebody could test, I would fix those problems. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-fcdproplus for OSX
Not quite yet. I'll send you a pull request shortly. - MLD On Jan 20, 2014, at 8:31 AM, Michael Dickens michael.dick...@ettus.com wrote: Awesome; I'll try it out shortly. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] B100 clock with UHD
Hi, I run B100 with OpenBTS. I thought the reconfigurable clock on B100 board would run with OpenBTS at 52MHz but I actually measure the sampling clock as 64MHz. So, where is the resampling done? Is the driver Transceiver52MHz used with B100 or not? Can someone shine some light on how it actually works? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] B100 clock with UHD
Hi Robert - The B100 has a configurable clock rate, specifically so that applications that require specific clock rates can tune it accordingly (e.g., OpenBTS). You can pass master_clock_rate=rate into the args string of the device and set the master clock rate to what works for your application. I haven't personally used OpenBTS recently, but if you aren't resampling on the host, that is probably how the host is using the device. Cheers, Ben On Mon, Jan 20, 2014 at 8:29 AM, Robert Light robert.li...@gmx.de wrote: Hi, I run B100 with OpenBTS. I thought the reconfigurable clock on B100 board would run with OpenBTS at 52MHz but I actually measure the sampling clock as 64MHz. So, where is the resampling done? Is the driver Transceiver52MHz used with B100 or not? Can someone shine some light on how it actually works? ___ 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] Passing a USRP pointer
On Fri, Jan 17, 2014 at 5:40 PM, Tom Rondeau t...@trondeau.com wrote: On Tue, Jan 14, 2014 at 9:09 PM, Dan CaJacob dan.caja...@gmail.com wrote: Hey Tom, The block worked fine with the right symblic name passed! The amp is getting PTTed now in 3.7 Thanks for your help with this! Great! It still seems weird that the USRP Sink symbolic name was formatted differently, though. Hm, yes, that is odd. Would you open a ticket about it? Low priority and a change in behavior that might have to wait for 3.8. Will do! Also, would it be possible to automatically register symbolic name aliases that are based on the block names created in GRC/python? That would make the lookup a little more obvious. Which names, exactly? Are you talking about the variable name itself? I'm not sure what the nomenclature is, but I am talking about the name that is auto-generated by GRC when a block is placed, but which can be modified by the user. This name becomes the blocks object name in the python file. For that, there's no way for the block to know that information. On the other hand, you can actually set the block alias yourself so you don't have to ask/guess/know what it is in advance using the set_block_alias(string) function. I am aware of the alias function. The question is - can we use that somewhere so that the block automatically gets aliased as the name the block instance is given in GRC? Probably, this needs to live in GRC itself, specifically in the code that generates a python file from the FG. Does that make sense? I assume the alias function is a method of the block objects in python. Thanks for your help with this, Tom! I'm really excited about 3.7! I'm already using it on one of my flatsat setups. Tom Thanks! Very Respectfully, Dan CaJacob On Fri, Jan 10, 2014 at 3:28 PM, Dan CaJacob dan.caja...@gmail.com wrote: Hey Tom, We've been working on this, but we ran into a snag. We couldn't seem to look up the usrp sink block's key. Other blocks could be looked up with the keys we expected, just not the uhd sink. I just un-commented a print statement in block_registry.cc so that we could see how each block actually gets registered, built it and ran a simple flowgraph. The flowgraph is just a signal source - throttle - uhd sink. Here's the output: register_symbolic_name: top_block0 register_symbolic_name: gr uhd usrp sink0 register_symbolic_name: throttle0 register_symbolic_name: sig_source_c0 The UHD sink block gets an unexpected gr pre-pended and the underscores are replaced with spaces. We are going to attempt our OOT blocks with this in mind, but I thought I'd give you a heads up on this behavior. Thanks! Very Respectfully, Dan CaJacob On Tue, Jan 7, 2014 at 2:18 PM, Tom Rondeau t...@trondeau.com wrote: On Tue, Jan 7, 2014 at 12:21 PM, Dan CaJacob dan.caja...@gmail.com wrote: Hey Tom, Here's some more detail into our problem. When running the flowgraph, we get the following error: File /usr/local/lib/python2.7/dist-packages/sq/sq_swig.py, line 679, in make return _sq_swig.usrp_pa_control_make(*args, **kwargs) TypeError: in method 'usrp_pa_control_make', argument 1 of type 'gr::uhd::usrp_sink::sptr' When setting up a FG, the pa-control block accepts a reference to the downstream UHD sink. I have attached the specific block source. Thanks! Very Respectfully, Dan CaJacob It's probably the difference between a gr::uhd::usrp_sink and a gr::uhd::usrp_sink_impl. A safer way to handle this might be to use the new(ish) block_registry that we implemented to handle the message passing infrastructure. You can get a basic_block_sptr from global_block_registry.block_lookup; you should then be able to cast this to a usrp_sink_sptr. You'll pass it a PMT symbol containing the alias name of the UHD sink itself. Take a look at basic_block.cc for a look at how the global_block_registry is used. I've not done exactly this before, so it might not go completely smoothly, and I'd be interested in your experience. In general, this sounds like something more appropriately implemented as a message, though, but that would mean changing the gr-uhd code. Having a message handler for the GPIO stuff would probably be useful if done generically enough. Tom On Mon, Jan 6, 2014 at 11:25 AM, Dan CaJacob dan.caja...@gmail.com wrote: Thanks Tom, No problem. I hope you and the rest of the community had relaxing holidays! I hope to have some better info for you by tomorrow, if not before. Another way to look at this is: does it make sense to keep doing things this way? Is there a better way to reference the downstream USRP and toggle the IO? I could imagine an async message stream or specific stream-tags, but both would probably
