[Discuss-gnuradio] GRCon18: Lost & Found: Apple USB-C Charger
Hi all, found a 87 W Apple USB-C charger in one of the conference rooms. If it's yours and you're still at the venue I'll drop it at the front desk, else I'll take it back to the Ettus Research office. Cheers, Moritz ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [USRP-users] [UHD] Coarse roadmap for USRP E310 Software
Hi Philip, On Wed, Jul 18, 2018 at 9:33 AM, Philip Balister wrote: > On 07/17/2018 01:50 PM, Moritz Fischer via USRP-users wrote: >> Philip, >> >> On Fri, Jul 13, 2018 at 8:03 AM, Philip Balister wrote: >>> A couple of notes based on updating the E300 to rocko >>> >>> 1) The N310 branch added a bbappend on something called salt which added >>> the need for the meta-openstack and meta-virtualization layers. For >>> basic E300 support, this is crazy layer bloat. I removed the bbappend. >>> If you really need it, I'd create a layer for specific applications, >>> salt seems to be some form of enterprise software config management >>> system ( https://en.wikipedia.org/wiki/Salt_(software) ) Certainly not >>> every E300 project needs this. >> >> That's a good point, I'll look into making it more modular. >> >>> >>> 2) The uhd recipe in meta-sdr needs updating. I'd suggest moving it to >>> meta-ettus, but it also supports users using other Ettus products with >>> other embedded hardware, so the recipe doesn't belong there. It would be >>> silly having to add the meta-ettus bsp to use a b200 with a pi-s. >> >> I have made an attempt at splitting up meta-ettus more into separate layers, >> the result of that is on github (master). I was hesitant to push it public >> since >> in it current form E31x does not work. N310 will move over to that (and the >> sumo >> release with the next release). >> >> Personally having the uhd recipe in meta-sdr was not convenient and we ended >> up >> building most of the filesystems with bbappends to the UHD recipe >> anyways, so I've >> decided to host the UHD recipe in meta-ettus in a meta-ettus-core sublayer. > > Well, moving it out of meta-sdr means I'll need to drop the uhd > packagegroups and have the default images not include any usrp hardware, > including things like the b200. Since uhd doesn't build in master, I'll > go ahead and drop uhd and associated bitsfrom meta-sdr there. > > I suspect this might make things easier for engineering development, but > long term, I think it will be harder for end users to use usrps with > random dev boards. Time will tell. We can iterate on it if it doesn't work out for people. Thanks, Moritz ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [USRP-users] [UHD] Coarse roadmap for USRP E310 Software
Philip, On Fri, Jul 13, 2018 at 8:03 AM, Philip Balister wrote: > A couple of notes based on updating the E300 to rocko > > 1) The N310 branch added a bbappend on something called salt which added > the need for the meta-openstack and meta-virtualization layers. For > basic E300 support, this is crazy layer bloat. I removed the bbappend. > If you really need it, I'd create a layer for specific applications, > salt seems to be some form of enterprise software config management > system ( https://en.wikipedia.org/wiki/Salt_(software) ) Certainly not > every E300 project needs this. That's a good point, I'll look into making it more modular. > > 2) The uhd recipe in meta-sdr needs updating. I'd suggest moving it to > meta-ettus, but it also supports users using other Ettus products with > other embedded hardware, so the recipe doesn't belong there. It would be > silly having to add the meta-ettus bsp to use a b200 with a pi-s. I have made an attempt at splitting up meta-ettus more into separate layers, the result of that is on github (master). I was hesitant to push it public since in it current form E31x does not work. N310 will move over to that (and the sumo release with the next release). Personally having the uhd recipe in meta-sdr was not convenient and we ended up building most of the filesystems with bbappends to the UHD recipe anyways, so I've decided to host the UHD recipe in meta-ettus in a meta-ettus-core sublayer. With upcoming products I hope the modularization makes sense and helps keeping changes separate while not reinventing the wheel every time. > 3) While messing with uhd, it is time to have the firmware recipe > package the fpga files on a per device basis, instead of all images on > one package. We are/were already working on that. Thanks for your input. Cheers, Moritz ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Front Panel GPIO on Ettus X310
Ciao Maurizio,
On Mon, Aug 31, 2015 at 9:03 AM, Crozzoli Maurizio
wrote:
> Moritz,
> if you wanted to scare me, you succeeded!
That wasn't my intend, sorry. I merely tried to elaborate on different
factors that might play into the choice of solution that will work
best for your solution.
>
> What you propose goes far beyond my current skills and it also looks
> excessively complicated compared to my needs: really no easier way to detect
> an external trigger?
I'm still not clear on how tight your latency requirements for that
trigger detection are. If you are ok to just poll with a 'slow'
software loop then using the get_gpio_attr() function will probably be
fast enough.
>
> Furthermore I cannot understand the meaning of the example in "The E3x0/X3x0
> Front Panel GPIO" manual:
>
> "We are also using GPIO4, which we want to control manually, as an output.
> [...]
> // set up our values for ATR control: 1 for ATR, 0 for manual
> [...]
> After the above code is run, the ATR in the FPGA will automatically control
> GPIO6, as we have described, based on the radio state, and we have direct
> manual control over GPIO4."
What this means is that the GPIO6 will be controlled by the ATR's
logic, while the GPIO4 is user controlled via the set_gpio_attr()
functions, i.e. the state of GPIO6 is controlled by the radio state
{tx,rx,xx} while GPIO4 is controlled by API calls.
>
> So, what does it mean "After the above code is run, [...] we have direct
> manual control over GPIO4."? It thought it could be the solution to my need
> (a GPIO port to read an external trigger - except for the GPIO direction, a
> detail) but according to what you write (which is coherent with the
> introduction of the cited manual page: "These GPIO pins are controlled
> directly by the FPGA, where they are controlled by an ATR (Automatic Transmit
> / Receive).") it looks it is not: could you please explain the point?
See above. As you correctly observed you just want to set the mode to
manual control (so the FPGA's state machine will not interfere), and
control the GPIOs using {get,set}_gpio_attr, possibly in a separate
thread.
>
> TIA!
>
> BR,
> Maurizio.
>
> -Messaggio originale-
> Da: Moritz Fischer [mailto:moritz.fisc...@ettus.com]
> Inviato: mercoledì 5 agosto 2015 23:56
> A: Crozzoli Maurizio
> Cc: discuss-gnuradio@gnu.org
> Oggetto: Re: [Discuss-gnuradio] Front Panel GPIO on Ettus X310
>
> Maurizio,
>
> On Wed, Aug 5, 2015 at 7:49 AM, Maurizio Crozzoli
> wrote:
>> Hi Martin or others who can support me, I have a problem which is
>> similar as Frank's: I have an E310 and I want to receive a and
>> external trigger on a pin which starts an acquisition process of a
>> burst of samples from the radio source.
>
> In the default FPGA image the GPIO pins are wired up to ATR pins that are
> connected to the radio0.
>
> https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300.v#L112
> https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300.v#L375
> https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300.v#L659
> https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300_core.v#L304
>
> would be your places to start.
>
> If you want to use our GPIO API take a look at:
>
> http://files.ettus.com/manual/page_gpio_api.html
>
>>
>> Stated that I have to remove the box around the E310 to have access to
>> the GPIO ports (not a problem!), according to what I have read so far
>> in this thread, no way to reach my goal but using C++ (no GRC!). Not
>> an easy task for me but I do hope I can do it.
>>
>> What I need you support about is related to the right approach I
>> should follow. I would think that I should write a "while" loop which
>> runs in ARM processors where one on the available GPIO port is constantly
>> monitored:
>> when the trigger is detected the acquisition process of a burst of
>> samples from the radio source is started and, once it has been
>> completed, the flow goes back to the GPIO port monitoring.
>
> You could either fork of a thread to monitor the ports through the UHD API,
> or rewire stuff in the FPGA (as pointed out above) to use the Zynq's GPIO_I
> signals in the FPGA.
> You could then use the default kernel sysfs GPIO API to use GPIO interrupts.
>
> places to start investigating are:
>
> https://www.kernel.org/doc/Documentation/gpio/sysfs.txt
> http://elinux.org/GPIO#GPIO_interrupts_from_user_space
>
> maybe there are python bindings available?
>
>>
>> Is there any example code I be inspired from? OF course I have to
>> study wh
Re: [Discuss-gnuradio] Front Panel GPIO on Ettus X310
Maurizio, On Wed, Aug 5, 2015 at 7:49 AM, Maurizio Crozzoli wrote: > Hi Martin or others who can support me, > I have a problem which is similar as Frank's: I have an E310 and I want to > receive a and external trigger on a pin which starts an acquisition process > of a burst of samples from the radio source. In the default FPGA image the GPIO pins are wired up to ATR pins that are connected to the radio0. https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300.v#L112 https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300.v#L375 https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300.v#L659 https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300_core.v#L304 would be your places to start. If you want to use our GPIO API take a look at: http://files.ettus.com/manual/page_gpio_api.html > > Stated that I have to remove the box around the E310 to have access to the > GPIO ports (not a problem!), according to what I have read so far in this > thread, no way to reach my goal but using C++ (no GRC!). Not an easy task > for me but I do hope I can do it. > > What I need you support about is related to the right approach I should > follow. I would think that I should write a "while" loop which runs in ARM > processors where one on the available GPIO port is constantly monitored: > when the trigger is detected the acquisition process of a burst of samples > from the radio source is started and, once it has been completed, the flow > goes back to the GPIO port monitoring. You could either fork of a thread to monitor the ports through the UHD API, or rewire stuff in the FPGA (as pointed out above) to use the Zynq's GPIO_I signals in the FPGA. You could then use the default kernel sysfs GPIO API to use GPIO interrupts. places to start investigating are: https://www.kernel.org/doc/Documentation/gpio/sysfs.txt http://elinux.org/GPIO#GPIO_interrupts_from_user_space maybe there are python bindings available? > > Is there any example code I be inspired from? OF course I have to study what > can be found in the manual page "The E3x0/X3x0 Front Panel GPIO", but, > together with the suggested gpio.cpp example under UHD, it looks like there > is more emphasis on the ATR mechanism, which - I think - has nothing to do > with the problem I have to solve. That is true, see the above links. Depending on latency requirements, and your input signal, the ATR API might not be what you need. > > Martin or others, could you please comment on my problem? > > TIA! > > BR, > Maurizio. > > PS If you think that, according to what I have understood so far, I will > need to use RFNoC in order to cope with the sampling speed constraints of > the acquisition process of a burst of samples from the radio source, you > might well understand how much I need your help, and not just for this > post... Just for the GPIO part no requirement of using RFNOC. > > > > -- > View this message in context: > http://gnuradio.4.n7.nabble.com/Front-Panel-GPIO-on-Ettus-X310-tp53979p55274.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 Happy hacking, Moritz ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Costum FPGA in E310
Hi Weidong, so you can write software for the PS as linux user mode process, I don't know what interface your custom IP exposes so it's hard to give guidance. The Zynq platform relies on AXI interfaces. If your IP uses older busses you might be able to find bridges in Xilinx's coregen. You might want to look into RFNoC if you do any kind of streaming based design. We don't plan to support any kind of XPS workflow at this point. Cheers, Moritz On Mon, Apr 13, 2015 at 10:02 AM, lassena wrote: > Hi Moritz, > > Thanks for your reply. > > I need to migrate a project realized on virtix4 to E310. This project has > custom ip code of digital signal process on the both side of PS and PL. And > we use the standalone system in Microblaze. > > If I don't misunderstand you, you mean the fpga project which I downloaded > from git can be modified only in the PL? Is it possible I could get a > version of XPS project I can custom my own design on the both side PS and > PL? > > Thanks again, > > > > <http://twitter.com/lassenaets> <http://twitter.com/lassenaets> > <http://twitter.com/lassenaets>* <http://twitter.com/lassenaets> > <http://www.facebook.com/lassena.etsmtl.ca>* > > > > > > > > > > > > > > *Weidong Wang | Étudiant à la MaîtriseLaboratoire LASSENADépartement du > génie électriqueÉcole de technologie supérieure | 1100, rue Notre-Dame > Ouest | Montréal (Qc) Canada | H3C 1K3Tel.: 514 396-8800, poste 7930 | > Bureau : A-2566 | www.etsmtl.ca <http://www.etsmtl.ca/>Cell. : 514 > 568-9667Email : weidong. wang@lassena.etsmtl.caLASSENA : lassena.etsmtl.ca > <http://lassena.etsmtl.ca/> > ---L’ÉTS > est une constituante du réseau de l’Université du > Québec-Avis: > L'information contenue dans ce courriel est strictement confidentielle. > Toute utilisation par une personne autre que le destinataire est illégale. > Si vous recevez ce courriel par erreur, veuillez svp le détruire et nous en > aviser.-Notice: > The information contained in this message is strictly confidential. Any use > thereof by any person other than the named recipient(s) is illegal. If you > are not the intended recipient please advise sender and delete this > message. <http://www.facebook.com/lassena.etsmtl.ca>* > * <http://www.facebook.com/lassena.etsmtl.ca>* > On 2015-04-12, at 14:03, Moritz Fischer wrote: > > Hi Weidong, > > the XPS project that's made during the current E310 build is not meant > to be used to implement custom designs. > We usually just add stuff to the Makefiles (custom RTL, coregen files, > etc). If you can give us some more info on what you're trying to do, > we'll be able to help you out better. > > Cheers, > > Moritz > > On Sat, Apr 11, 2015 at 10:41 AM, linux > wrote: > > Hi all, > > > I am actually working on a project needs migrate an old FPGA program to > > E310. First, I want to custom the official FPGA program of E310. But I > found > > some configurations of PS are not the same on the schematics diagram. And I > > tried to export to SDK, but even the simple hello world program didn't > work. > > > I listed what I have done as follow: > > > 1. first, I downloaded the FPGA source code from this address: > > https://github.com/EttusResearch/fpga/tree/master > > > 2. I taped these commands to build the project: > > $source /opt/Xilinx/14.7/ISE_DS/setting64.sh > > $export PATH=$PATH: /opt/Xilinx/14.7/ISE_DS/ISE/bin/bin/lin64/xtclsh > > $cd fpga-master/usrp3/top/e300 > > $make E310 > > > 3. This step took about 1 hour. And then, I open the XPS project. > > $cd build-E310/zynq-ps > > $xps e300_ps.xmp > > > 4. The XPS was just opened. But from here I found some settings I don’t > > understand. In the ZYNQ PS CONFIGURATION, the UART1 was selected using MIO > > 48 … 49, but in the schematic diagram of USRP E300 series Motherboard, the > > UART was using UART0. And UART0 used MIO 14 and MIO 15. > > > 5. If I tried to generate the bitstream from this XPS project, it will give > > me a lot of errors like: > > > ERROR:MapLib:979 - LUT6 symbol > > > > "axi_interconnect_1/axi_interconnect_1/mi_protocol_conv_bank/gen_protocol_slot[0].gen_prot_conv.conv_inst/gen_axi3.axi3_co
Re: [Discuss-gnuradio] Costum FPGA in E310
Hi Weidong, the XPS project that's made during the current E310 build is not meant to be used to implement custom designs. We usually just add stuff to the Makefiles (custom RTL, coregen files, etc). If you can give us some more info on what you're trying to do, we'll be able to help you out better. Cheers, Moritz On Sat, Apr 11, 2015 at 10:41 AM, linux wrote: > Hi all, > > I am actually working on a project needs migrate an old FPGA program to > E310. First, I want to custom the official FPGA program of E310. But I found > some configurations of PS are not the same on the schematics diagram. And I > tried to export to SDK, but even the simple hello world program didn't work. > > I listed what I have done as follow: > > 1. first, I downloaded the FPGA source code from this address: > https://github.com/EttusResearch/fpga/tree/master > > 2. I taped these commands to build the project: > $source /opt/Xilinx/14.7/ISE_DS/setting64.sh > $export PATH=$PATH: /opt/Xilinx/14.7/ISE_DS/ISE/bin/bin/lin64/xtclsh > $cd fpga-master/usrp3/top/e300 > $make E310 > > 3. This step took about 1 hour. And then, I open the XPS project. > $cd build-E310/zynq-ps > $xps e300_ps.xmp > > 4. The XPS was just opened. But from here I found some settings I don’t > understand. In the ZYNQ PS CONFIGURATION, the UART1 was selected using MIO > 48 … 49, but in the schematic diagram of USRP E300 series Motherboard, the > UART was using UART0. And UART0 used MIO 14 and MIO 15. > > 5. If I tried to generate the bitstream from this XPS project, it will give > me a lot of errors like: > > ERROR:MapLib:979 - LUT6 symbol > > "axi_interconnect_1/axi_interconnect_1/mi_protocol_conv_bank/gen_protocol_slot[0].gen_prot_conv.conv_inst/gen_axi3.axi3_conv_inst/USE_READ.USE_SPLIT.read_addr_inst/Madd_M_AXI_AADDR_I[31]_GND_19_o_add_51_OUT_lut<10>" > (output > signal=axi_interconnect_1/axi_interconnect_1/mi_protocol_conv_bank/gen_protocol_slot[0].gen_prot_conv.conv_inst/gen_axi3.axi3_conv_inst/USE_READ.USE_SPLIT.read_addr_inst/Madd_M_AXI_AADDR_I[31]_GND_19_o_add_51_OUT_lut<10>) > has input signal > "axi_interconnect_1/axi_interconnect_1/mi_protocol_conv_bank/gen_protocol_slot[0].gen_prot_conv.conv_inst/gen_axi3.axi3_conv_inst/USE_READ.USE_SPLIT.read_addr_inst/S_AXI_AADDR_Q<10>" > which will be trimmed. See Section 5 of the Map Report File for details > about why the input signal will become undriven. > > 6. Finally, I exported design to SDK with no bitstream, but even the simple > Hello world print program didn't work. There was nothing output from the > UART port. > > I want know if there is someone have done a similar work who can tell me > where am I doing wrong? > > > Thanks, > > Weidong Wang > > > > > > ___ > 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] UHD build apparently failed
Hi all, thanks for testing. Parts of that is already internally fixed on our branches for the rest I created patches. I expect this to be pushed to the public master in the next days. Thanks for hanging in there, Moritz On Mon, Mar 24, 2014 at 12:11 AM, Marcus D. Leech wrote: > On 03/23/2014 07:08 PM, Marcus Müller wrote: > > This calls for #include ; I wonder how that is working on my f19 > > Yup, that took care of it. > > Then there's the b200_iface.cpp problem with libusb on my system not > having libusb_error_name, so I had to copy the macro from > transport/zero_copy that's conditional on HAVE_LIBUSB_ERROR_NAME, and > it all compiled just fine. > > > > > -- > Marcus Leech > Principal Investigator > Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org > > > ___ > 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] UHD build apparently failed
Hi Marcuses, on my machine it builds without the include. Can you confirm that? Cheers, Moritz On Sun, Mar 23, 2014 at 7:42 PM, Marcus Müller wrote: > boost::container is quite new (introduced in 1.48 afaik); I'm pulling > master right now, but boost::container::vector should be STL-compatible. > replace the incluse by #include and try ;) > > > On 03/23/2014 06:10 PM, Marcus D. Leech wrote: > > On 03/23/2014 12:08 PM, Moritz Fischer wrote: > > Hi Marcus, > > On Sun, Mar 23, 2014 at 3:24 PM, Marcus D. Leech wrote: > >> Here's a bit of git log of what I'm building: >> >> commit a8caec5f93976c081d488118f53a72dca49efdf6 >> Author: Ashish Chaudhari >> Date: Wed Feb 19 19:22:52 2014 -0800 >> >> b200: Fixed bug in rx_dsp_core_3000 that would assume 3 halfbands and >> X300 s >> > > Crap, that's 7 commits down from the fix in our internal master. I'll > see if I can get stuff pushed tomorrow. > > In the meantime you can try the attached patch. > > Happy hacking, > > Moritz > > It got further, the nirio stuff made it past, but, then: > > /home/mleech/uhd/host/include/uhd/transport/nirio/nirio_fifo.ipp:377:24: > warning: expected [error|warning|ignored] after '#pragma GCC diagnostic' > [ 44%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/dboard_base.cpp.o > [ 44%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/dboard_eeprom.cpp.o > [ 44%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/dboard_id.cpp.o > [ 45%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/dboard_iface.cpp.o > [ 45%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/dboard_manager.cpp.o > [ 46%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/gps_ctrl.cpp.o > /home/mleech/uhd/host/lib/usrp/gps_ctrl.cpp:33:38: fatal error: > boost/container/vector.hpp: No such file or directory > compilation terminated. > make[2]: *** [lib/CMakeFiles/uhd.dir/usrp/gps_ctrl.cpp.o] Error 1 > make[1]: *** [lib/CMakeFiles/uhd.dir/all] Error 2 > make: *** [all] Error 2 > > > > -- > Marcus Leech > Principal Investigator > Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org > > > > ___ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://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] UHD build apparently failed
Hi Marcus,
On Sun, Mar 23, 2014 at 3:24 PM, Marcus D. Leech wrote:
> Here's a bit of git log of what I'm building:
>
> commit a8caec5f93976c081d488118f53a72dca49efdf6
> Author: Ashish Chaudhari
> Date: Wed Feb 19 19:22:52 2014 -0800
>
> b200: Fixed bug in rx_dsp_core_3000 that would assume 3 halfbands and
> X300 s
>
Crap, that's 7 commits down from the fix in our internal master. I'll see
if I can get stuff pushed tomorrow.
In the meantime you can try the attached patch.
Happy hacking,
Moritz
From 573d39c8b33b2f16ba6bd8d007423e5df315ad02 Mon Sep 17 00:00:00 2001
From: Moritz
Date: Mon, 23 Dec 2013 10:40:54 +0100
Subject: [PATCH] rpc: Make usrp3 compile again on RHEL6.
* boost::asio::connect appears in boost 1.47
added conditional for older machines
* boost::system::get_system_category() instead of
boost::system::system_category.
Signed-off-by: Moritz
---
host/lib/transport/nirio/rpc/rpc_client.cpp | 36 +
1 file changed, 27 insertions(+), 9 deletions(-)
diff --git a/host/lib/transport/nirio/rpc/rpc_client.cpp b/host/lib/transport/nirio/rpc/rpc_client.cpp
index a5f8cf4..c16a844 100644
--- a/host/lib/transport/nirio/rpc/rpc_client.cpp
+++ b/host/lib/transport/nirio/rpc/rpc_client.cpp
@@ -17,7 +17,9 @@
#include
#include
+#include
#include
+#include
#define CHAIN_BLOCKING_XFER(func, exp, status) \
if (status) { \
@@ -48,7 +50,23 @@ rpc_client::rpc_client (
tcp::resolver resolver(_io_service);
tcp::resolver::query query(tcp::v4(), server, port);
tcp::resolver::iterator iterator = resolver.resolve(query);
-boost::asio::connect(_socket, iterator);
+
+#if BOOST_VERSION < 104700
+// default constructor creates end iterator
+tcp::resolver::iterator end;
+
+boost::system::error_code error = boost::asio::error::host_not_found;
+while (error && iterator != end)
+{
+_socket.close();
+_socket.connect(*iterator++, error);
+}
+if (error)
+throw boost::system::system_error(error);
+#else
+boost::asio::connect(_socket, iterator);
+#endif
+
UHD_LOG << "rpc_client connected to server." << std::endl;
try {
@@ -74,18 +92,18 @@ rpc_client::rpc_client (
_io_service_thread.reset(new boost::thread(boost::bind(&boost::asio::io_service::run, &_io_service)));
} else {
UHD_LOG << "rpc_client handshake failed." << std::endl;
-_exec_err.assign(boost::asio::error::connection_refused, boost::system::system_category());
+_exec_err.assign(boost::asio::error::connection_refused, boost::asio::error::get_system_category());
}
UHD_LOG << boost::format("rpc_client archive = %d, rpc_server archive = %d\n.") %
_hshake_args_client.boost_archive_version %
_hshake_args_server.boost_archive_version;
} catch (boost::exception&) {
UHD_LOG << "rpc_client handshake aborted." << std::endl;
-_exec_err.assign(boost::asio::error::connection_refused, boost::system::system_category());
+_exec_err.assign(boost::asio::error::connection_refused, boost::asio::error::get_system_category());
}
} catch (boost::exception&) {
UHD_LOG << "rpc_client connection request cancelled/aborted." << std::endl;
-_exec_err.assign(boost::asio::error::connection_aborted, boost::system::system_category());
+_exec_err.assign(boost::asio::error::connection_aborted, boost::asio::error::get_system_category());
}
}
@@ -126,18 +144,18 @@ const boost::system::error_code& rpc_client::call(
if (status) {
if (!_exec_gate.timed_wait(lock, timeout)) {
UHD_LOG << "rpc_client function timed out." << std::endl;
-_exec_err.assign(boost::asio::error::timed_out, boost::system::system_category());
+_exec_err.assign(boost::asio::error::timed_out, boost::asio::error::get_system_category());
}
} else {
UHD_LOG << "rpc_client connection dropped." << std::endl;
-_exec_err.assign(boost::asio::error::connection_aborted, boost::system::system_category());
+_exec_err.assign(boost::asio::error::connection_aborted, boost::asio::error::get_system_category());
_stop_io_service();
}
//Verify that we are talking to the correct endpoint
if ((_request.header.client_id != _response.header.client_id) && !_exec_err) {
UHD_LOG << "rpc_client confused about who its talking to." << std::endl;
-_exec_err.assign(boost::asio::error::operation_aborted, boost::system::system_category());
+_exec_err.assign(boost::asio::error::operation_aborted, boost::asio::error::get_system_category());
}
i
Re: [Discuss-gnuradio] UHD build apparently failed
Hi Marcus, Sara I think I fixed this somewhen back in december, when RHEL6 support broke. Which branch (tag) are you building off? UHD 3.7.0 (master) should have those changes. Cheers, Moritz On Sat, Mar 22, 2014 at 2:55 AM, Marcus D. Leech wrote: > On 03/21/2014 09:40 PM, Sara Chérif wrote: > > As I am installing GNU Radio from this link: > > http://blogs.bu.edu/mhirsch/2012/07/installing-gnu-radio-in-ubuntu-12-04-x64/comment-page-1/ > (which installs GNU Radio & UHD ) > I got the following error , what can i do ? Thanks :) > > [ 26%] Building CXX object > lib/CMakeFiles/uhd.dir/transport/nirio/rpc/rpc_client.cpp.o > /home/dell/GNUradio/uhd/host/lib/transport/nirio/rpc/rpc_client.cpp: In > constructor 'uhd::usrprio_rpc::rpc_client::rpc_client(const string&, const > string&, uint32_t, uint32_t)': > /home/dell/GNUradio/uhd/host/lib/transport/nirio/rpc/rpc_client.cpp:51:9: > error: 'connect' is not a member of 'boost::asio' > /home/dell/GNUradio/uhd/host/lib/transport/nirio/rpc/rpc_client.cpp:51:9: > note: suggested alternatives: > /usr/include/x86_64-linux-gnu/sys/socket.h:129:12: note: 'connect' > /usr/include/boost/asio/detail/impl/socket_ops.ipp:383:5: note: > 'boost::asio::detail::socket_ops::connect' > make[2]: *** [lib/CMakeFiles/uhd.dir/transport/nirio/rpc/rpc_client.cpp.o] > Error 1 > make[1]: *** [lib/CMakeFiles/uhd.dir/all] Error 2 > make: *** [all] Error 2 > UHD build apparently failed > Exiting UHD build > Send success/fail info to sbrac.org? > > > ___ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > I see the same problem on Fedora 14, and even when I specify: > > -DENABLE_X300=OFF > > In the cmake, I still see this build failure due to nirio requiring a > newer boost. > > Ben/Michael have you a comment? > > > > -- > Marcus Leech > Principal Investigator > Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org > > > ___ > 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] maxtrix inverse
Well you could implement your Matrix inversion using VOLK, of course. But to my knowledge you'd have to write the necessary kernels yourself. Cheers, Moritz On Thu, Mar 20, 2014 at 12:13 PM, Nasi wrote: > Can we replace Eigen with VOLK in some extent? > > - > NE > > Понедельник, 17 марта 2014, 11:50 +01:00 от Moritz Fischer < > moritz.fisc...@ettus.com>: > > Hi BZS, > > Eigen is a pretty good library. Other's that might come to might is > using blas/lapack in fortran or armadillo. I wouldn't expect too much > of a speedup when compared to Eigen though. For examples on how to use > fortran or armadillo with GNU Radio look at the gr-specest out of tree > module. > > Cheers, > > Moritz > > On Mon, Mar 17, 2014 at 8:49 AM, 猪猪头 > <794226...@qq.com<https://e.mail.ru/compose?To=794226...@qq.com>> > wrote: > > hi, > > when i deal data in my block,i want to scramble the positions symbol in a > > frame,and at receiver-end descramble these symbols,get correct the > > order,for this purpose,i need to compute the inverse of 64*64 matrix,and > > when i used the eigen library ,it works slowly wnen compare with the deal > > data speed of gnuradio,anyone could give me some other libraries or other > > methods to satify my need, > > thanks , > > BZS > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org<https://e.mail.ru/compose?To=discuss%2dgnura...@gnu.org> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org<https://e.mail.ru/compose?To=discuss%2dgnura...@gnu.org> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > -- > NE > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Google Summer of Code 2014 applicant : Optimization with VOLK
Abhishek, On Wed, Mar 19, 2014 at 4:53 PM, Abhishek Bhowmick wrote: > My current hardware doesn't support AVX2. How practical is it to develop > software for AVX2 intrinsics using Intel's SW Development Emulator (and > possible performance testing on a remote machine) ? I'm fairly confident we can get you a login to a AVX2 machine if there's no other option. Cheers, Moritz ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] maxtrix inverse
Hi BZS, Eigen is a pretty good library. Other's that might come to might is using blas/lapack in fortran or armadillo. I wouldn't expect too much of a speedup when compared to Eigen though. For examples on how to use fortran or armadillo with GNU Radio look at the gr-specest out of tree module. Cheers, Moritz On Mon, Mar 17, 2014 at 8:49 AM, 猪猪头 <794226...@qq.com> wrote: > hi, > when i deal data in my block,i want to scramble the positions symbol in a > frame,and at receiver-end descramble these symbols,get correct the > order,for this purpose,i need to compute the inverse of 64*64 matrix,and > when i used the eigen library ,it works slowly wnen compare with the deal > data speed of gnuradio,anyone could give me some other libraries or other > methods to satify my need, > thanks , > BZS > > ___ > 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] use of gr-specest
On Mar 8, 2014 7:38 PM, "Chandan Pradhan" wrote: > > can the gr-specest be used to implement root music algorithm for direction finding?? Yes. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Converting from #ifndef/#define include guards to #pragma once globally
Hi Marcus,
some quick Google research found several contradictory sources. [1]
calls it 'non standard but widely supported'.
Since we build on weird platforms I think we should make absolutely
sure that this is the way things should be done ^{TM}.
Some other sources listed this as a potential speedup for compilation
on Visual Studio. Discuss.
Personally I don't have an issue with header guards because there
exist plenty of plugins for {vim,emacs, whatever},
to do it for you.
Happy hacking,
Moritz
[1] http://en.wikipedia.org/wiki/Pragma_once
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [User Experience] Hangout Thursday
Hey guys, another cool thing I forgot to mention during the call would be to have something like planet.debian.org (with s/debian/gnuradio/ of course). Moritz ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Simple Tx/Rx setup
Kamarisam, I really hope you're using an attenuator in between the two devices. I'm not terribly familiar with bladerf's frontend but if it works similar to our devices, you'll fry them if you don't attenuate the TX signal going through the SMA cable. Cheers, Moritz ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Matrices in gnuradio
Hi Omar, you can have a look at the gr-specest toolbox. There are blocks using LAPACK in Fortran (MUSIC / ESPRIT) as well as examples using Armadillo (a C++ linear algebra library) to perform fast matrix computations. Cheers & happy hacking Moritz On Thu, May 9, 2013 at 6:08 PM, Dan CaJacob wrote: > Probably not the way you think, but if you needed to perform a > linear-algebra operation as part of a block's work function, you could use > numpy, if you write the block in python or a linear-algebra library if you > are working in C++. > > Very Respectfully, > > Dan CaJacob > > > On Thu, May 9, 2013 at 9:15 AM, Omar11 wrote: > >> Hello >> >> Does it exist matrix data types in gnuradio ? >> >> Omar >> >> >> >> -- >> View this message in context: >> http://gnuradio.4.n7.nabble.com/Matrices-in-gnuradio-tp41239.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 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] Gabor transform to GNU Radio
Hi Adriana, We currently do not (directly) support STFTs in GNU Radio. If you can go with a wavelet transform instead you might want to have a look at gr-wavelet & gsl. Otherwise maybe you can take some of our fftw based code and modify it into doing STFTs? Keep us posted if you get it working, or need help. Cheers, Moritz ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SpecEst toolbox install issue
Hi Marius, On 12/16/2011 10:56 AM, Marius wrote: I have a small issue with the SpecEst toolbox install from cgran: https://www.cgran.org/wiki/SpecEst#HowToInstall I followed that Howto and the Readme. It compiled just fine on my Ubuntu 11.04, x64, v3.4.0-101-g7e2b45b8 Good starting point ;-) ImportError: libgnuradio-specest.so: cannot open shared object file: No such file or directory Normally these variables are not set, but I configured them... sometimes this worked: % echo $PYTHONPATH :/usr/local/lib64/pkgconfig:/usr/local/lib64/ % echo $PKG_CONFIG_PATH :/usr/local/lib64/pkgconfig No effect. I performaed ldconfig after install and there are no errors. The lib is in /usr/local/lib64/ Can you check /usr/local/lib64 is in your library path? Do you get the same error if you do a: export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib64 before launching the command? If yes, you might want to add /usr/local/lib64 to a file in your /etc/ld.so.conf.d Cheers, Moritz ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] which math library to link with
On 12/02/2011 02:05 PM, Marcus Müller wrote: Martin Braun wrote: > [1] But perhaps they're reading this and would like to comment. Indeed ;-) Conclusion: Try the GSL, it's SVD methods should work quite fine. If you don't like gsl, try armadillo. If you're fine with fortran and LAPACK: Do it. Write a C header file for your Fortran functions and call them. Build a fortran shared library and link it to your c++ library. Do math. Really fast. Um ...I agree with, use GSL if it works for you. However I have to say that the upstream armadillo code does weird stuff for matrices < 64x64 (they propose their own matrix multiplication algorithm which for our case was _horribly_ slow). As Martin pointed out, see the SpecEst Toolbox on how to do stuff wit CMake. If you'd rather use autotools, contact me off list, I should still have the project lying around somewhere. I also started the gr-linalg toolbox back in 2009, but never had the time to work on it. It has an example for SVD though, however I haven't tried it since ages ... might need some tweaking, might be even broken... Cheers and happy hacking, Moritz ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] blocks coding guide
As always, good job. Do you ever sleep ;-) Cheers & happy hacking, Moritz ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New to GnuRadio (Fortran own blocks?)
On 11/26/2011 09:18 AM, Uzair Baig wrote: > Here is what I am planning. I am thinking of writing my own Fortran blocks > (we are a team of 4 so yes that is possible) and integrating that with > python; NumPy and then use that to connect with other basic blocks. Another way to use Fortran in GNU Radio is to wrap them in a C++ block, you might want to have a look at [0] to see how we did that. This however supposes that you actually want to use the GNU Radio runtime to write a GNU Radio application (which I'm not entirely sure of is what you want to do). Maybe you could elaborate further on what you are actually planning to do? > Please tell me if that will work (as in how much efficient would that be), and > whether there is a way round understanding the blocks. If I understand you correctly you want to have an answer on how efficient that is and if it is possible to do this *without* understanding the blocks?! > We are okay in making our own Fortran blocks and working, but we need to be > sure. And would really like if we can find some book/manual to understand > on what convention was the blocks already existing made, etc, so we use > most of the existing work done. I think there is no official convention for writing Fortran blocks in GNU Radio, but for coding guidelines see README.hacking. May I ask a final question, why did you select Fortran? Do you have a lot of matrix computations to do? In our case we used Fortran for several reasons including wanting to learn how to do it, and (to our knowledge) the lack of equally fast implementations in C/C++ of the matrix computations involved. Cheers & happy hacking, Moritz [0] http://github.com/kit-cel/gr-specest.git ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error installing gnuradio.
Hey there, I think I fixed it, can you give it another shot? I just updated the gnuradio-git PKGBUILD. Cheers, Moritz ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error installing gnuradio.
On 07/12/2011 09:55 AM, N.v wrote: Hello. I'm trying to compile gnuradio on arch linux from AUR (https://aur.archlinux.org/packages.php?ID=39425) I'm working on it ... there seems to be some other stuff besides of the nousrp.patch stuff. I'll keep you updated. Also you may check the attached patch. Cheers, Moritz >From e6fb610459cac0f01c3253de6fa87f6b485cb6b9 Mon Sep 17 00:00:00 2001 From: Moritz Fischer Date: Thu, 14 Jul 2011 18:51:50 +0200 Subject: [PATCH] Fixed some tab / whitespace issues. --- volk/gen/make_makefile_am.py |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/volk/gen/make_makefile_am.py b/volk/gen/make_makefile_am.py index d700626..f843b44 100644 --- a/volk/gen/make_makefile_am.py +++ b/volk/gen/make_makefile_am.py @@ -77,9 +77,9 @@ noinst_LTLIBRARIES = if archflags_dict[arch] != "none": tempstring += "-" + archflags_dict[arch] + " " - tempstring += "\nnoinst_LTLIBRARIES += libvolk_" + machine_name + ".la " +tempstring += "\nnoinst_LTLIBRARIES += libvolk_" + machine_name + ".la " tempstring += "\nlibvolk_la_LIBADD += libvolk_" + machine_name + ".la\n" - tempstring += "libvolk_la_CPPFLAGS += -DLV_MACHINE_" + machine_name.swapcase() + " \n" +tempstring += "libvolk_la_CPPFLAGS += -DLV_MACHINE_" + machine_name.swapcase() + " \n" tempstring += "endif\n" -- 1.7.6 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Radio out-of-tree module with CMake
Hey guys, while porting our Spectral Estimation Toolbox to CMake I realized, that the outcome [1] might be also interesting for other people. I threw out some stuff which most people will not need from our project (like linking our Fortran code) and adapted the ./create-gnuradio-out-of-tree-project [2] to download the tarball from my webserver. However, it still needs some testing and tweaking and feedback is always welcome. As I'm quite new to CMake there also might be some more elegant (less stupid) ways to do stuff. Also big thanks to Josh for doing the GNU Radio CMake port, that enabled me to borrow huge parts. All the best & happy hacking Moritz [1] https://github.com/mfischer/gr-specest [2] http://www.pure-entropy.org/~moe/create-out-of-tree ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-uhd swig troubles
On Wed, Apr 20, 2011 at 07:13:15PM +0200, Josh Blum wrote: > I think I see why: > > > //! Complex floating point (64-bit floats) range [-1.0, +1.0] > > COMPLEX_FLOAT64 = 'd', > > //! Complex floating point (32-bit floats) range [-1.0, +1.0] > > COMPLEX_FLOAT32 = 'f', > > //! Complex signed integer (16-bit integers) range [-32768, +32767] > > COMPLEX_INT16 = 's', > > //! Complex signed integer (8-bit integers) range [-128, 127] > > COMPLEX_INT8 ='b' > > Swig 2 is interpreting that as a string. Which in kind of nice, except > that things that use those enums in python expect type int. Swig seems to me like black magic ... on the other hand ... the whole gnuradio build process sometimes does ... > I dont know the magical swig switch to turn that off. Does this diff > make it work for you? If you didn't know it, you pushed it by accident or good guess ;-) It's working just fine now :-) Thanks again for your quick fix! All the best, Moritz pgpAFB9PgBL7g.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-uhd swig troubles
On Wed, Apr 20, 2011 at 06:28:45PM +0200, Josh Blum wrote: > What do other gnuradio enums give you? > > python -c "from gnuradio import gr; print type(gr.GR_COS_WAVE)" > > Can you create a gr.sig_source? Yeah, it's a > Just trying to narrow it down... Thanks for your efforts ;-) Moritz pgphoPs75ZrqP.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-uhd swig troubles
Hey guys, I started to have this with the git master and uhd from yesterday evening: linux; GNU C++ version 4.6.0 20110415 (prerelease); Boost_104600; UHD_003.000.001-8212f22 [...] ub/grotarapi/PHY/PhysicalLayer.py", line 47, in __init__ self.u_tx = uhd.usrp_sink(hint, io_type=uhd.io_type_t.COMPLEX_FLOAT32, num_channels=1) File "/usr/lib/python2.7/site-packages/gnuradio/uhd/__init__.py", line 73, in constructor_interceptor if kwargs.has_key(key): kwargs[key] = cast(kwargs[key]) File "/usr/lib/python2.7/site-packages/gnuradio/uhd/uhd_swig.py", line 409, in __init__ this = _uhd_swig.new_io_type_t(*args) NotImplementedError: Wrong number or type of arguments for overloaded function 'new_io_type_t'. Possible C/C++ prototypes are: uhd::io_type_t(uhd::io_type_t::tid_t) uhd::io_type_t(size_t) [...] If I try the same with a size_t instead (in bpython): a = uhd.usrp_sink(device_addr='type=usrp2', io_type=32, num_channels=1) # OUT: Traceback (most recent call last): # OUT: File "", line 1, in # OUT: File # "/usr/lib/python2.7/site-packages/gnuradio/uhd/__init__.py", line 74, # in constructor_interceptor # OUT: return old_constructor(*args, **kwargs) # OUT: File # "/usr/lib/python2.7/site-packages/gnuradio/uhd/uhd_swig.py", line # 1854, in usrp_sink # OUT: return _uhd_swig.usrp_sink(*args, **kwargs) # OUT: RuntimeError: gr_io_signature(3) Any hints how to fix this? Did someone already see something like this? I think it might be somehow related to 7787d1fc1aecc7b59e476c31865b4f32348cb729 All the best, Moritz pgp4ZgCzIiNmm.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Mail with picture
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/19/2011 08:01 PM, Gabriel Morel wrote: > Do you know how can I send a email with pictures. I just tried to send one > and he was fired. Just upload it somewhere and send a link. Like this the people that want to see it can see it, while the others save time and bandwidth. Moritz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJNN/YvAAoJEOjnDXL6I0uZXuEQAIgD9JdtBt3C7mHxXOIH0gU8 q0yMtvcIGdi9fDg6SikoEKfqggbcHV+OLsMLXjSssPy+818fPj3P7dt81+1X0hjM 0rm+yzRDeMDJZgmT5ivcPz34TG3qzXVlGikpCG3UPNPAylD4OgSn/8QLKRjn2Gpn dJCK07DUJ5nNJtlC/alevRrmcG9h5vdtCpu0zHDazRb/A+SzgQGRtH1iMHc+FF12 o05Vgo+3T4G/K7b3FqNhVVUAKFtJ48+ixkM1dUb3pvu/lml8V32c+jqQEayzPhGc RZKrN363SKBUS8q5wSpnBCnne3IFLEq6Sp1bw5JIn2k71kLe4EAvLfftQ7hJb8oO ibKXC3udliMl0MkdAjXFWdxSMqHqPQasVdCesRdtKsjCSsb+LOG8hVYBd/m7JCqQ eYQaIAfK9/MWICYjhIJZk/M8NyZOXoeCT1X4njanhihJMXzuAXQT+MIuoPuHyBa2 qdFY7kZ1wEo+3+wGV8MVG15vxuqnNbdlicXTGnucMmxoGgcTryDfL5KPQskW8xUJ GFiYlSr42Nf9H06BkAfdE1I1O/xgaw2t5ZJ6dnc82wjUMGkhkjwTcINg7T+BxX9h 5AQ5POq8Ew2vHbrLq2jd4KKYLso0sddvzNSaflU5vm4moEoAALNdNj38z+sf3/yX gu2eihh7oCTSBlRs8zbn =a3Jr -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Announcement - January 20th 2011
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/20/2011 09:05 AM, Josh Blum wrote: > [...] UHD will build and run under the clang compiler. Cool stuff! Thanks Josh :-) Cheers, Moritz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJNN/UPAAoJEOjnDXL6I0uZRqcP/1pU/Wf6XujpPRwKqu1stLz6 +9uLMnid53Vekl6nUkOFaJQaG8Rtm2+pqBqKAujhQqbp3jjRitkJ42/6Yl4y8UAc CDc8y7qLBSE/SdrnhQR5TkvROnpu6MkDvEoEYciVbvJ0n9gcpGAA+ptTL65LjoKh N9DPkY98UhJFjrf0Iocnajv8IM6TGb9+u9cpkmD2OqGh0npnJjHd3sHFE5q5fSoM jUmNDCROVj0DdfFb+rNB7QfDOuZDfbVRzM01eqYUIDxhxdpZsfIZkLkt3qaPjipS Pus6SYjFFiEQbz4qxAo+iPlfUXAqLaTY8ZRA7ag04kLYkipAIrxXmwMQSm9D4bHi +95Vd6h1Uw2Rq8PAFeqfFAi+Nwajy1z+C1zLnMgAWdAXlX7V+AOE7eJujSgLjhZG qs3lyPy4P+x297dH/f+L/ed+dKGvMCILnD3ykbI1ex5RpjrO/mxOrAZldXt1Y9VM eyItn1wyY4nQ4k3JN5CkhoSAnfEFqW/Cz5ekzuUnarmc8JfyZbrR00IN3/Kt5KOD BjM02Ll6n+oAUeN8IhoC6ub7HNrZAiFZrIODmmdB9R4UpzL3OqyWcccKDvzYwSrv f22aHBu8YwwPEgHyQKeuYCBui7Iyk+wfyLTDYGLP5FJDfuxOH6qg6t67GMyhX7vC PSdlJpDzdlaADKBP8IUB =5bvg -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to get the message content from gr.message_queue?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/23/2010 03:53 PM, Arief Marwanto wrote: > How to get the message content from gr.msg_quueue > Suppose I sent send packet (float A) what will I receive? Supposing you want to do packet based transmissions, you might want to have a look at the: gnuradio-examples/python/digital directory. If you actually want to use msg_queues from the python domain for something else you'll want to create some kind of watcher thread. Have a closer look at e.g.: gnuradio-core/src/python/gnuradio/blks2impl/pkt.py to see how it's done. Happy hacking, Moritz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJNE2zhAAoJEOjnDXL6I0uZst0P/2ZllvuGifc1uLgW9p9gyCeC h7Yxack3Cu3x+SvfmhFPYupssp5UHobkGrDP6DGA2ptEQQuksRBguIdZBnfxP484 uNnQWrPZthia0fr/K8fvUXCNtX3/hnWEJfWsrTG22xH5RPCAeRO3GmzCi0vwepRE cImLOenRAyL69eEuhoQ51FAsgYSNBirhKpbSVpdyBOl/x+RiO1MmGFIuWbIE7hJQ EuvJu5Ke0FV1onGoYa3YjAVzK1WeT3b1m6W+chQgLn4sHa/CpT1YAuY8HhpIhK4S FMTA7EevROJHg7SFwCink/3vWhSX2NnRHqPgPptq12na/D2mwRm4xMKF5/3WaQCd EG6MnBq/Cpn0JMouKkgJuw6t+OsY3OV6HyH4L1lRn5zZe689kTJwMfVD6g177Odg M+0kRBBKJjyhVxrDbYIYqn4XE3QOgoq/3VtNr090O9rF0h14jivY/tot8IHx9kM5 p8JgbBQCZjsnRfQJ32WT30ilmAJNzR90vMZvRpmH0d3tHrEbMIjEcgkI9igB4dKM YKLykMWNgIfxtRNj0hFFJ4cbo1FOg0YfQe8mIrp1OTklATq1AT1z8L3uSI25J4vs VICubH5QxoyLFCw9g9QuBRTKBxbgSS/gdwCZp2w3SOb6Q7GHAU/k0B/2nVf2QX7U odf+7aiGYk+x7GJydQpg =HN0M -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] python/digital examples and UHD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/29/2010 03:47 PM, Tom Rondeau wrote: Thanks for your reply Tom, >> Have you used the version 2 digital code, yet (benchmark_tx2, >> benchmark_rx2, usrp_receive_path2, etc.)? One of the things I did was >> include better resampling so that you can get any bit rate you want. >> You still have to go through the process of selecting the USRP's >> sample rate that's closest to your desired rate, and then the >> resampling takes care of the rest. Well in fact that's what I was looking at. I called this the 'automagical' frequency selection in my last mail ;-) It appears to me you do this by trying all the tuples of (bitrate, samples_per_symbol,...) and select the one fitting 'best'. So please don't throw stones at me for asking this question, but from my understanding the required desired_samplerate = bitrate x samples_per_symbol / bits_per_symbol (1) >> What I do with the UHD driver is ask for a sample rate. It will then >> set its sample rate to whatever the closest rate it can do. You can >> the read back the actual sample rate of the USRP with get_samp_rate(). >> I then use this value to determine the difference between my desired >> sample rate and the actual sample rate, which I then plug into the >> arbitrary resampler. So what you suggest is basically: 1. set_samp_rate(desired_samplerate) as in (1) 2. tmp = get_samp_rate() 3. and then resample in gnuradio according to tmp / desired_samplerate or did I get something wrong? Please don't get me wrong because I ask a lot of questions :-) I don't ask you guys to do any of my work (like a thesis or the likes). Just in my opinion having the examples working is really important, because that's where new people start to look at when trying to figure out how stuff works. And nothing is more frustrating than not even managing to get the examples running. Best regards and happy hacking, Moritz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJM9L5tAAoJEOjnDXL6I0uZtNwP/1JDIggYhvBRw6bJQmQzUjKU mDKrYyqIdFbLDv0+aC62gTn0g+OVpa11yP585pZcF9tZ5A9ZwIqSEpo6iEPXH883 q6+A3GmogTAqtaydf7seG3PkdV/HXZcAkBRtd0QgjMykKbIOG2hlDTJZsv8Ru0Iz /dOa6ERrxHQSrYY1DLW/e5dMrwBp8SMGdIT3RlwpuKvQyZmA9xj8rcqxNyvfHuNf 3KT5AFCQQbKrmGXiwb9z+09rFTHWga4hdLbfkX+L4ANz/j2eUDxomLgSVcx1vOEb 0Qqn1MJu2vBRceIdyiAItl3gnocWZ62EQMnvIcoDY9F7Mi9sBCWVV18CWVwPv2SU P+4o5wRvpV5b7nVn6U0Yi47w0/Wfz5UsYbiGMc/scrpSa0wHuYv7BXsjlOOANrmd RAYz0Xvk6aIq4P4RuuqeIx1AWfw0tLcQaO7BAAvanZqf6qf+HqP+oMmCQZgWzlhL hgDuL/7YdpUN66c8xSXivCfFZpf/FOkoKMhF1N7BQ1EM349BrgbPdL3VO0I/jEs/ f7nsMML7FkhJdOF5IH/1QgEl+fGGMNvEmqBqfm3w/pYtUkwX4KDnc6GrHimYrk72 QnFuv2ZWURnyNsvp7pYnH27Bu7ssyYa6DZP+Iu047Ev7iK0oMuqaQaWxDibSSL4c vMqE5g//R0SsNBcTtiZe =x5g+ -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] python/digital examples and UHD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi list, over the weekend I spend some time trying to update the demos to work with the UHD, I just started playing with git, so if you see something stupid let me know ;-) I put what I got on (in the uhd-examples branch): g...@github.com:mfischer/gnuradio-mfischer.git However the part where it 'automagically' picks rx/tx bitrates is not really working as I have no idea how to detect what device I'm talking to. Also please note that as I don't have the right values for bitrates and samples_per_symbol don't be surprised if the examples crash ;-) The old generic_usrp.py had ranges for the possible decimation / interpolation factors as we don't have this in UHD I'm a bit confused on how to continue. I started to add a function samp_rate_range_t get_rx_samp_rate_range() to UHDs single_usrp_sink / multi_usrp_sink which internally would ask the corresponding _dev for the right ranges, depending on what device you're talking to. I still have to figure out the ranges part though. g...@github.com:mfischer/uhd-mfischer.git As I don't really have insight into the longtime plan for UHD, I'm not sure whether that's the way to go though... Can someone give me any hints whether this actually makes sense? Happy hacking, - -Moritz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJM82xBAAoJEOjnDXL6I0uZ4icQAJt3+Z82fs2LGRZ+4ndKVat0 DMPzRW1EN3T4EKIyAY9N4/weLwXvT5vuyKc+2i/mlPzhjS+ssJKfsnbLJNfNgK0Q Notdvyv1ItNZtrD2/l5MpM/dyR0dwVpLJnmF6jrH0zOX0yiBdah80/YAz5ISrxtm nKNmo0DJ/hZqWPQkklYbMrDirdLACPTzRwqh+JVJHBOOiVnoyXbmxakY2Ta1Ea+d 4BpOOV4h5daGQeC+9BKODY/aNtkemCvHBZdC3FQA/8IxnoRnJWTohT4Dyxc+Ypgo AKOaYUGk1uPuJ1JrCP1883umBBm5Pf4x4Obe0yJ8s3RXWuWB80f40Kx/Qbc4CXnG e3rXN50E4lF76JZm4bJqzlextQ28bXRVkeCM+AeaM/nTECRHaY2QhQhAWCA2iFCC /amJjdQpm8fiDk1gx1hpXWeQk2eyvx3Uy4Oe9L5JgiVMFBD+4yvwqIqGcRwIxo/i ladOfOTiJ9d0tcYXZ9Injg4QDAtHwtmFO8nF8WVnzvPlPHiGQaOwpgtJu7aPJRt/ +96HR/lT7VFCGmawJbsig4jbXgSQ0oxsRkJ6A+IxjCDN56wtABiyIdbu0575BU7w I/SjuIZ6xe9H+NFs/ZYmb5ImMiZFq2fV3Tn3ljZJrcaf1IMRQ+a2yoSgo4In5O7C +7H/Ru9tHCRR5J52m587 =AHQt -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using UHD failed to find USRP2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/17/2010 06:21 PM, Tom Rondeau wrote: > On Wed, Nov 17, 2010 at 8:37 AM, Josh Blum wrote: >> I long run plan is to replace benchmark* and tunnel apps with UHD and >> message passing blocks. For now, if you want to go about modding the >> examples to work with UHD, look for generic_usrp.py and usrp_options.py. You >> can wedge a uhd source and sink block in there in parallel with the usrp1 >> and 2 drivers. -Josh Well if someone is interested in a quick 'n' dirty hack, I could help out, because I modified the above files to provide a third type as Josh suggested. At least the benchmark_tx and benchmark_rx are working with it using USRP2s. It's quite ugly though and in my opinion, since UHD is already providing what generic_usrp.py is doing (more or less) and my fix only imitating the old API it's far from being really useful for more than a quick fix. > Yes, we want to eventually replace all existing examples and utilities > using USRP/USRP2 with the UHD driver. There are quite a few of these > programs to modify and get properly working. Yeah, but I guess the unified UHD interface simplifies this if we don't have to pay attention to break backwards compatibility. > So... I'm hoping that people will offer to help with the transition > process. If you do rework some of the existing functions and examples > with UHD, we would really appreciate you contributing it back to the > project, which will significantly speed up the work. I'll try to work on this / started working on it, but I can't promise anything ... ;-) I'll keep you updated. Happy hacking, Moritz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJM8FXCAAoJEOjnDXL6I0uZxAwQAJ8TaTuwYhSJWlqHk95G3vfm O4zCaKEucN9ZbKZ3PplGpVZRPgSZtRpxRf94PNX97uSHwQjJGTUlp3lv1njndvzJ t3B7cPhhW2Cz8nCtP4ucTeHbaFngzU0wEHCJlyHVgLd3WGai3bb3R6EqHUhzpMJ4 FCB4vVBe1QHWjBTl/cvdU1A1viAXSQSM0fB0GQfMu39r5sDAspa8coSWCy9UoFSd /+gfTcZ+YqehOi2/lUW/srUpdSIy0gPGKviHDM0uIGFAjOWZYm/yuprPqWWlM3kG bxr3F9xJspR0ZKxM1bWdz440bHrGgDPMGNU63jB7on4ROH9bFpNAotPFPhCJGrmD YdmkOMuBQExNwrK5lvf5t4xv1Cri5GnTBpyBFpQM1k+S+wPevfERSOPUKw6QVzQQ fzSPZzzFHzaPMhyvgDirvDp7xaJ1CNvuhRUM4WFv8ewIHE6rTiK8KXY6rESMFD4q rVdhSUSjqqsVTC4URGvKAfvBV9XDXcmGlQ2/qY3/Pn14+Mgcbf8xpRLASKcRCfyK BeRNmyM1lj4t8wcBx44J7WIO6b/1mW4+FO9Iiae1LmGLStsGTi/lWLatrvNtucqY KHLZWAnhFwP5CuD0HwjJq2K9jLAHFg37FCv+tYryEKCePhnLngA9wr4rpBX9l1O6 xlZEfYEnNLCGaHnNzw6a =/dlq -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd::tune_result_t vs. usrp2::tune_result
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/25/2010 05:44 PM, Josh Blum wrote: > In UHD, you set the sample rate. However for usrp2 and usrp1 gnuradio > drivers, you set the decimation and interpolation and the sample rate is > implied to be codec_rate/decim. Ok, I got it working now for some of the demos (benchmark_tx/rx), however it's far from looking nice enough for a merge ;-) While looking at the code I was wondering whether we still have to support the 'legacy' interface on next. If not, I'll attempt to throw out the old stuff from the digital examples and just use the uhd sources/sinks for the examples;UHD should, if compiled with support for USRP1, automatically select the right sources/sinks as far as I know(?) at least that's what it does in my tests. Now if I connect say two USRP2s and one USRP1, is there any way to influence the order in which they'll be selected? For the USRP2s the 'addr=...' parameter seems to work, but how would I do the same to select one USRP2 and one USRP1? And now for something completely different ;-) While playing with the USRP1 it occured to me, that I had to manually copy the std.ihx from $PREFIX/share/usrp/rev4/std.ihx to $PREFIX/share/uhd/images/usrp1_fw.ihx in order to get UHD to find the USRP1. Looking at line 64 and following in host/lib/usrp/usrp1/usrp1_impl.cpp in UHD, if I got it right, we search for a file called 'usrp1_fw.ihx'. Did I miss some under the hood magic or is this file 'missing' in the images package? Again thanks and happy hacking, Moritz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJM78maAAoJEOjnDXL6I0uZB2AP/2p2+nu0YAl4EiySXNGpjUc8 bwXgz4wwheoeFlTmNrI3c6I2swePyFaeXq8nSRGiKy5N0LbQmlhfsKnCB3Nyq59q d+9y6gq4v6XCazjXNrz3uK1/tI9tbZU3oKPRxy1kMCfBZzNM5369U906sa42uHEw RCC3IzEr69V8asxHM31BYapdivt2r1lrH1oY7MQxkbA09NKerlW3ln8ltIYnoxj1 OMPeR3Ed0ve6Fz72TRaB0EgewVxXwujmpnyRTlZDEx0RaNSc4iBZICE4kPRxnn4L HJ0B2hsURUXZhGPOZMSlD39Q0iY/bGC/wJje+ZVRyHy7j+Q00GiL9bzWTWZwPKVE SKiQbs0Ni6zu1Z4Q9F5JPs6uz7hBu+PbqC2CkOramu1+9r6u+O7EitaKrcj+tUs5 9+1Hoh5xi15hel2/mtkmN+/rG/E2X0IiLGu9goib4BAvVtslZXUB+gpvskq43Jl4 96kmCH4Sha4dzGM6IExfpbMrv2Grd4Kw+r6e7q75r/Orr1+JWG6Y65tY9xCm0qq0 TSyRS+JwL1dTgzT8ml8ZrOsPpTrTdK8o2r7fxEGTr+7JCq2z4WH1j9mP6miEYLRI q0KrAfh8+zb0CDNc4TIpsWXGNbCd3O9V6uICy1IXK4XYgNLNLH91xZlRtk5JaQYM OvQbHIpQ8/oQPijWul9V =F+ws -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] uhd::tune_result_t vs. usrp2::tune_result
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi list, I'm currently trying to adapt the gnuradio-core/src/python/gnuradio/blks2impl/generic_usrp.py to work with the gr-uhd modules to (re)enable the use of UHD with the gnuradio-examples/python/digital stuff. I'm a bit confused with the return value of the set_center_freq of the uhd_single_usrp_source. What I tried was to map the values of the uhd::tune_result_t into a usrp_tune_result. Does this make any sense to you guys? ;-) Another question that arose while looking at the code concerns the change in the way we set the sample rate: Why do we have in the new UHD source: set_samp_rate (double rate) versus: set_decim (int decimation_factor) in the old USRP source? Thanks for your time again & happy hacking - -Moritz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJM7mLVAAoJEOjnDXL6I0uZpHMP/28s/A98djBGYaeanGp54MXY khFV6Ltx0vsCNv6Uf4oJTsBdxhcqPX3x3YYbXCf5k7MXyQXxj23OrHVMtl2niVbc kbh2V710OTQEIC940ARrumPVTVDJ+A8vN76XGGGowZtJjMGaPYb20vyKkhqN5FWC k6+xhi/DUBCWIWWE/fyefP0zl3VhSIbV4L5zjWtoX/A1NTeTKZsq+UcsKz6ZVDCl UmZPBvav2PAIYpo99zvB3qZcxCPaGata09ZKsV03OeiUKG9yI1yUCXgj5tzhRNs2 dJFIAJAhkvI4rzV/GCYHI2WUuql758iCCPTbE4DLYBzyST/Eg5h1jveQetObIGpy PGMRGKv4jXg3BUQN6gxrI7SN2ZGSs8i+oxJdmu7pr1Zwnc3DxAVX9HgupfjARray MbO9RqbFKPoaWSwIJj6/SpNvVb/0b9zHPrN2UQWW31LfL4NS/3Ku5iTf3Fm5lx8l 7qLg+vJ4K35FO0iV/WIrOu+SHLPE8jiqlaaOgMC2pFfpqueLIMf5EXn0usiDgLjl IrvdxBzvMfPI4H+4UiNoMq3OD9v0jBFvaIGcFqPmVlqKr93N/GNT/sRYgxxOIXpw +4nzu5sRB2uFJa+4ABUs6RrJ8QvSzzkZW72rXk0hYNygn8IuUX8YkQMgifEQ19KZ WLgxSrO5FnWPUkYL+X7i =EbAB -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How can I skip N ites for each input?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/25/2010 08:39 AM, Songsong Gee wrote: > Suppose a sequence 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 > 0 0 1 0 0 0 0 0 0 0 > (one 1, seven 0's and repeat forever) > I want to take just '1' for EVERY time > So I place and connect 'Skip Head' block and set 'Num items' 7, which means > it skips first 7 items. Is there a specific reason to not just skip the first seven items in your block? Something like starting your processing at in[7] instead of in[0] with a sync/sync decimator block? Happy hacking, Moritz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJM7iODAAoJEOjnDXL6I0uZMvMQALmr002jAAP+E59JTz1tIEmv tTN1W6ddzFvJQwypiUOg0BMwIp+vd8PprdEI/HaqSsJx5o/gQNgTzFc1zjz7Mcx3 UrTPiqLY96h4RU6vikLJEHWk437R2kNXZBEKJ+/gY4ImzJk6IzZ5XMyrKFkqLEMG rAvEFKPr0r+wl8ERhERrAK7KtRnUTLU8vWWnr8oLLB0aPTlXx6JxTYwKMFyUsPgi VaqdiT/b4xqd0txRgVcYYpji/T09Nz4FSLAF3EmL7bOf1PLhiCcFOSLIFs+4sEvW XTfios1wC8MgQWdeBSCRChShsC7vCksvvJCtuFN/8SUAQ/EwVplQgj2KW/Pbu5Jv vejR4QgTx9xokLo0uamph3/2KkujxmEvz5n0FUk9l0GlZ5yuBXc5l50fi3rzo9Rd 0ogQIxxl+g/T88JxgBBkDq+sV8Vmvl+B/bx90+0eBIY0Qatu+Vo5+5wCs5dYsOqb 7MrNeXa4Xyp5Kzea1nz4nA4ZKArxjdFS3evUkjNZSEGv6EbSBiqy/SRDoBMJZ2si WytoKAfvq7ejpA7wpZ10VZEQNXE1QB9NdCKKiDC7BPS/DcdVMOAzcv1WDj49pUH2 cyg9WCS8ksm+FpPlON/ZVcQl49fyapnnr2HE6h6wKL+EswBVsq4F+qAiHjrugYrp WcLDAtLx3LaeCWIxSAXa =Kuz6 -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Announcement - November 23rd 2010
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/24/2010 07:11 PM, Josh Blum wrote: > I believe that that UHD was missing a case for the the revision number > in your usrp2 (possibly 3.1) and was falling through to a register map > intended for the USRP-N210. Can you pull the latest host code (just > updated) and try again? Works like a charm (even through a switch!) Thanks a lot! Cheers & happy hacking Moritz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJM7Wu/AAoJEOjnDXL6I0uZaWwQAIl6Nzp1x7AzBrzVWmzwpw79 aOmoJvUc/J+ka375EgaVs1OJb7Tjrnbh7Yz1bQKk+fJRzrvfYFtBGin6tBiRpdpo oLri1sh7m71QCQoaHtXGFizNRXTcEF0FUj4DtTmdEK3jABLgNPgtEuEcdVJe/qZ2 HkwV4bXR9Swf4kw27Ii4mm2RfN0cLrsMt66RLUYtDzzXqymj+ZUW3GaUp7wn8Gxq FH72f/UHugk58pB6wCcvRyYnTu37Jvtl22our7YFRk5NGPiUr/ZAOsGg6kTRzPSh 0saoG7+DsmuCzp/z4zIXotIVxKMHJYzk0h0QRPuvBY2Oy4NiHe1lIz5cVyAqaPz7 F8yw974uOqi8y+7P5DcKwVE6LOZhsCJYQpixCTOfR7kWOKEyegKsPIA5DcQ5vUQh TewCmxMlJhoz4vTzt0qWWT9XPdtiDaeB+Ee457P7Am0fnb61o5fWclAp5dpgnVB/ XRkMH1f7zfxyFHVZCItE5quOspnq/33NmZ9GdQAHsRisSaNMmYHpW+odQb3QaQRi vSyyWsLUI1R7Z6UgDZMohpdLZm7WSWqlQoEFHqLoWe6R2rMT6tBLbm0ILY/TnKII uzRT/7XWMKwgPZfAd/TuvbQaGDE/PbFmOwJ8EeE3vTCquV227cGIVIl9MeAD4lwT 07gfiynE0vtA2Zyfxyb4 =4JBp -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Announcement - November 23rd 2010
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/24/2010 05:45 PM, Matt Ettus wrote: The working one is revision 3.0 // serial number 149. The one that's not responding is a revision 3.01 // serial number 186. Sorry for not including this information ;-) Looking back now I feel kind of stupid to not have realized they might be of a different revision :-) Cheers, Moritz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJM7VHFAAoJEOjnDXL6I0uZrL0P/10tfWx2OTw/otuHaeeWceZB 5guPtmpaHdXVdTSkGktYzkMtRSQA1VBcMHKzC+b0KKypm/m/wU7Ij59GyjKx1+45 BUNZ/pfYHK6oroo3wycBavUIYqTrDq+CWv2EA/sc4dk8uxI38SpFJXlFHPG8akmL E+UkYerQyLKqVX55rI9DtDFGQ09+80sliVeeMOjMM2hegCcYxOpeA4zb6h6VpBMW XkJ3I6d7lDgArWB4cwfgHzVzaivqpz+B6d4/PnSnFeIAHFvZX0qP5ya9rX62yB/H TXvrzgtjM3v/IS1Fk1V4wOwMfVey9xIy25TcBawu9xFPMbLqic0yA42dMyUUzDXb POHDkaxDuAXDK+s4n9Pi2zH9fn4rshbYDzgWWnysH+RG4vUGqUtT3amxec6NaQWE seQcOaPY+iy2SJSoEwPiZAtjU4F0CUSO35cD2P2Nmlr6N7GICswgMkNnfjMbrPpQ lzkYo8Y6v/OAoQhNRbtFDfobUqES/j8lkjk1Fd5tmI3xpiGxb6qgU85vEiSczLkv iLW4hZk4nbr9ofI4YllOQeGe6QC8BRyBF7dGv62BOT67Mcu5e4pgFRkNJKxJFJg6 o1HOddj/MUtIwmq6wuvFHBnLw1KYQi7DGdy1c8Jjp3Bi3TnYYuBpQJ+6sk52+I7+ +a6ODpANG+Sjaf0Y8oB/ =OgZM -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Announcement - November 23rd 2010
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/24/2010 04:24 AM, Josh Blum wrote: > -- Feedback is welcome! Hi list, first of all thanks Josh for the great work. Now for the feedback part: While playing around with our USRP2s I noticed some odd behavior with the new fw/fpga images. My setup is Arch Linux(amd64), with latest gnuradio-git + uhd-git with two (seemingly identical) USRP2s. When putting the current images on the first one, it works just fine! Now if I use the *same* SD-card in the *other* USRP2 I get an odd response: linux; GNU C++ version 4.5.1; Boost_104300; UHD_0001.20101124034736.b33c109 Warning: Ignoring discovered device Expected fpga compatibility number 3, but got 852885540: The fpga build is not compatible with the host code build. whereas if I install the old image I get: linux; GNU C++ version 4.5.1; Boost_104300; UHD_0001.20101124034736.b33c109 Warning: Ignoring discovered device Expected protocol compatibility number 7, but got 6: The firmware build is not compatible with the host code build. which seems quite normal. Any ideas? Cheers, Moritz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJM7TwEAAoJEOjnDXL6I0uZZ7gQALn8CQjtgy0a4Sf1aysE8o54 L6CoZ1gHk2ijG8B539yVSTGDvGIT5QfQi5AUg+YukXMp3d4VSr+49xxRg7bsiWR6 JHpcnLVS378ookDhVVEtVk2piLj8zZtAuTkSbBeh5JxTR9es5CoxhBL0KmT931W5 F1HpYwWGPovwmVNyHJIGPyluV/HLZ+x2rJ+9TTe/aJHY6PK9p8hRYAYeis4fEHDz vVje9bgpB11WmO5Zk7pYLkDnZ/zTrw6ZixwrfLo2e6t7YmzMlXAnYXW5xbsN8yLQ V3hFDZXEiw8qtRS/rTOLsEFA9kCIjYtjPVLT1+wd3Of/XPi80K0Rgtb1G9ENPsAS PKPRcHjZWQMDIHE6UexAovXxaGuXtej+80tOWO7wjZ5Y1HptrjaQqvxXBL1k2s7A NdVhawPpvXeyYIH4Jc2T8AYH24g202jYuExdqYiJtEeqs0j1ZeLPr77ZXz9+AeaP V0fGfcsJjO/LvkDD2Bp274cLLps8USAMHAPZfO2nUu2EvMTMpSx5ihOonHGX3u+z B9/e9QsKdnOUmUgu9LpNuapWwJ23c2t/VeaOPreqXX1sWHV4vmlPNhcObwEMWlK2 IfTOpLhJk0dI2+QOxWgq/PD5Y/LGtku2wJFivIEdZsQ9QFLHNcuiRmHPj4BqQfSg QeIZfosxUZEBpztOsCVn =UF28 -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Helper script to automatically add blocks
On Tue, Aug 17, 2010 at 11:56:20AM -0700, George Nychis wrote:
> I have some tools I could add to it myself. I think "devtools" was the
> right thing to do. Hopefully several people will contribute other tools to
> it. I will move it to the top of the Projects page.
Another interesting thing in this context could be what toolset/ setup
people are using for their 'daily' GNU Radio development.
Although I know there's a lot of people out there (like me) quite happy with
their setup of vim + gdb + {insertyourtoolhere} grown over the years it might
be interesting to have a plugin for eclipse or something of this kind. (read:
less scary for beginners). Some time back I experimented around with writing a
plugin for eclipse, since at our institute a lot of people getting into
contact with GNU Radio for the first time are quite intimidated by the rather
let's say ... not overly comfortable autotools.
Please don't start throwing rocks already ;-)
Beeing not a real java programmer and running out of time for exams I haven't
achieved a lot yet but nevertheless to me it seemed like a good place to try
since eclipse's wizard structure does conform quite well with the usual
everyday programming tasks for out of tree modules / applications.
Maybe a frontend to Martin's script might be another approach worth trying.
So maybe if we add information on work in progress / unfinished projects and
ideas for future devtools to the wikipage we might find people with common
interests.
So far,
Moritz
pgpx7fKRbMPs5.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build failing, any ideas?
On Mon, Aug 16, 2010 at 01:18:25PM -0700, Eric Blossom wrote: > The bug is fixed in the master, maint and next git branches. > Also, there shouldn't be a need to specify the --with-boost-thread and > --with-boost-program-options options. Thanks a lot, for me it still needs the configure line, though. I managed to put a gnuradio stable PKGBUILD into Arch's AUR repos. Cheers pgpMKATyHPSxx.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Build failing, any ideas?
Hi List, I have been trying for a considerable amount of time now to build either 3.3.0 stable or 3.3.1git and always fail at this point: http://pastebin.com/ss7c356x I noticed while googling around that someone pasted a (as it seems to me) similar error a while before under: http://pastebin.com/7nB0DbEh but I could not find the corresponding message to the list. I'm using Boost 1.43.1 with gcc 4.5.1 on amd64 and my configure line looks like: ./configure --prefix=/usr --with-boost-thread=mt --with-boost-program-options=mt All the best and thanks for your help (again), Moritz pgpWAZMCdKAHO.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] New Archlinux PKGBUILD gnuradio-git
Hi List, just wanted to let you guys know that I created a PKGBUILD to create a gnuradio package with the current git version, since the old svn one was out of date. It's available via: http://aur.archlinux.org/packages.php?ID=39425 I'd like to add this to the wiki, too. Best regards, Moritz ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Possible to build such a multiple input system on USRP/USRP2 ?
On Tue, 2009-12-22 at 00:35 -0500, senlin peng wrote: > I want to build a multiple input system with four incoming channels > based on USRP/USRP2. The incoming samples of these four channels must > be synchronized and feed into one computer. The center frequencies of > these four channels are different, but they are within the range of > the DBSRX daughter board. My experiences showed me, that the DBSRX doesn't work that well in multiantenna systems with synchronisation (in general for synchronisation). I'd go for RFX1800s instead (in case you have the choice) > My question is how many USRP/USRP2 boards I > need? If you manage to synchronize two USRPs then two, if you go for USRP2s afaik it's 4. > Are there any examples about building a multiple input system? In case of USRPs check the multiusrp code, I submitted a patch to get it running with trunk some time ago. But I did not check since then. Cheers, Moritz signature.asc Description: This is a digitally signed message part ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] LAPACK/BLAS with GNURadio
Dear List,
I was trying to implement some LAPACK/BLAS(liblapack as included in
Ubuntu) wrappers for GNURadio since I haven't found anything to do
matrix/vector operations in GNURadio but I haven't found out how to do a
clever conversion from Fortran's (more precise the f2c) way of dealing
with complex numbers ( a C-struct ):
extern "C"
{
struct{
float real;
float imag;
} complex;
}
to the GNURadio way:
std::complex
and back.
My C++ knowledge on alignment etc. is too limited, up to now I just
copied them, since reinterpret_cast<> or static_cast<> only work for
certain architecture / alignment combinations. So if anyone has some
ideas please let me know.
Cheers,
Moritz
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] multi_usrp examples in trunk
On Fri, 2009-08-07 at 12:59 -0700, Eric Blossom wrote: > It would be great to have it running. Please fix it and send a patch. I'll do that, after trying for a whole day, I finally sent the message to the list, and about 20mins later I managed to make some progress :-/ However I still have not managed to get the '-s' switch for attaching the counters to the scopesink to work together with 4 channels. I'll have another look and sent the patch next week. If I will still be to stupid to complete the somewhat simple task of determining the correct number of inputs for the scope with 4 channels and '-s' switch from options.nchan and options.show_counters I will cry again to the list for help ;-) Does someone know what the maximum number of channels one can attach to the scopesink2 is? > FWIW, the reason it's still there is so that somebody who cares (== you) > doesn't have to start from zero ;-) :-) Best regards, Moritz signature.asc Description: This is a digitally signed message part ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] multi_usrp examples in trunk
Hi all, after some time searching through the list archives I was not able to find out what happened to the multi_usrp.py file which is needed to run the the multi_usrp/multi_usrp_rx_cfile.py and multi_usrp/multi_usrp_rx_oscope.py in the examples directory. I found in the svn log, that they haven't been converted to hier_block2 yet. (Rev. 7607 afaik) After changing some code in usrp_multi.py and manually copying it to the python dist-packages directory, I was able to run the multi_usrp/multi_usrp_rx_cfile.py, which *seemed* to work fine. Looking at the samples in Octave they seemed fine too. However I was not able to get the multi_usrp_rx_oscope.py to run, as I was not able to convert the scopesink stuff in it to scopesink2. Although it's flagged as unsupported, I think it would be nice to have this kind of examples running. If there's interest in fixing this I could send my changes for others to check. If there's no interest in fixing it I don't see the point in keeping the example in current versions. Best regards, Moritz signature.asc Description: This is a digitally signed message part ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
