Re: [Discuss-gnuradio] USRP source + UHD driver and data formatting
On 02/21/2011 10:04 PM, Almohanad Fayez wrote: > > > > Did the USRP IQ data format change in the UHD driver? The data from > the USRP1 used to be 15-bit fixed point, or something like that, is > it now normalized floating point data? I'm asking because I have > code that moves data from the USRP to a Fixed-point DSP and it seems > I have to redo the data conversion part so can someone explain to me > the new IQ data format? > > Also is this the same data format expected for the USRP sink? > Yes, all floating points are normalized to 1.0. Integers are not. See: http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1io__type__t.html#acbe526dddf5132355528c41e58c85dfa -josh > thanks > > al fayez > > > > > > > ___ Discuss-gnuradio > mailing list Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP source + UHD driver and data formatting
Did the USRP IQ data format change in the UHD driver? The data from the USRP1 used to be 15-bit fixed point, or something like that, is it now normalized floating point data? I'm asking because I have code that moves data from the USRP to a Fixed-point DSP and it seems I have to redo the data conversion part so can someone explain to me the new IQ data format? Also is this the same data format expected for the USRP sink? thanks al fayez ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] how do I submit updates?
I had some time and finished updating gr-trellis with serial/parallel encoders and decoders. I also refactored all heavy-duty algorithms ()such as viterbi, siso, turbo, etc) and used templates for simplicity. I have these updates on branch "turbo" on my github site: https://github.com/anastas/gnuradio_turbo.git What is the process for submitting those for merging with master? thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The 'next' branch
On 02/21/2011 07:50 PM, Don Ward wrote: > Tom Rondeau wrote: > >> I would ask all of you who can to start either using or at least >> testing out the 'next' branch now and provide us with feedback and bug >> reports. > > Compilation on Cygwin fails because there is no (#included > by volk_complex.h) in Cygwin. In fact, there appears to be no support > in the Cygwin C library for complex types > (http://www.cygwin.com/cygwin-api/std-notimpl.html). (Complex numbers > are supported in Cygwin's g++, however.) > > Unless there is some reasonable way to avoid requiring complex.h (or to > avoid building volk), we will need to abandon GNU Radio under Cygwin. > (That wouldn't bother me too much, as long as it works under > MinGW---especially if support could be provided building with MSVC.) > Totally working on that last part. :-) -josh > -- Don W. > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The 'next' branch
On Mon, Feb 21, 2011 at 10:50 PM, Don Ward wrote: > Tom Rondeau wrote: > >> I would ask all of you who can to start either using or at least >> testing out the 'next' branch now and provide us with feedback and bug >> reports. > > Compilation on Cygwin fails because there is no (#included by > volk_complex.h) in Cygwin. In fact, there appears to be no support in the > Cygwin C library for complex types > (http://www.cygwin.com/cygwin-api/std-notimpl.html). (Complex numbers are > supported in Cygwin's g++, however.) > > Unless there is some reasonable way to avoid requiring complex.h (or to > avoid building volk), we will need to abandon GNU Radio under Cygwin. (That > wouldn't bother me too much, as long as it works under MinGW---especially if > support could be provided building with MSVC.) > > -- Don W. Thanks, Don. That's really good to know and wouldn't have even crossed my mind (the more I have to interact with Cygwin, the less impressed I get). Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to stop the top_block and restart signal transmission
On Mon, Feb 21, 2011 at 9:50 PM, Yan Nie wrote: > Dear all, > I'm trying to stop top_block implementing the signal transmission for 5 > milliseconds and then restart the signal transmission at the transmitter > side, by using the tb.stop() then time.sleep(0.005) to suspend the system > for 5 milliseconds then tb.start() to start the signal transmission again. > This approach gives an > RuntimeError: top_block::start: top block already running or wait() not > called after previous stop(). > Could you please help me to find what the problem is? I also tried lock() > and unlock() which cannot stop the signal transmission implemented in > top_block Yan, You want to use the lock() and unlock(). They should pause and unpause the graph, so please elaborate when you say that they don't stop the signal transmission. The start and stop methods will definitely not work here. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GR Conference Dates
The GNU Radio conference has been scheduled for September 14 - 16, 2011. We will start after lunch at 1 PM on Wednesday and end 5 PM on Friday. I am currently planning on having some space reserved on Saturday for an informal hack session. The conference will be held in Levine Hall of the University of Pennsylvania, Philadelphia, PA. There will be plenty more information to come about location, hotels, transportation, etc., but you can use this to start planning. After looking at the feedback from everyone, this time seemed like not only the best time of the week but also the best dates. As per a previous suggestion (from Jens, if I recall), this occurs right after PIMRC in Toronto, so hopefully anyone in this general area of the world for that could piggyback onto that trip. I recognize that this won't work for everyone, but hopefully with this lead time, many of you can plan your schedules accordingly. Please let me know if you are planning and able to attend. The better idea that I have for the number of people coming, the smoother a process I can make this. I know that cost is going to be a factor for many of you, and I'm afraid that I can't speculate as to what it will be costing at this point. My intention is that the conference is designed to not make any money, and so cost for attending will be based on the cost of putting it together. For that, the more people who I know can make it, the better I can estimate the registration fee. I expect/hope that it will not be too much (expect travel and hotel costs to outweigh the fee). Thanks, Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The 'next' branch
Tom Rondeau wrote: I would ask all of you who can to start either using or at least testing out the 'next' branch now and provide us with feedback and bug reports. Compilation on Cygwin fails because there is no (#included by volk_complex.h) in Cygwin. In fact, there appears to be no support in the Cygwin C library for complex types (http://www.cygwin.com/cygwin-api/std-notimpl.html). (Complex numbers are supported in Cygwin's g++, however.) Unless there is some reasonable way to avoid requiring complex.h (or to avoid building volk), we will need to abandon GNU Radio under Cygwin. (That wouldn't bother me too much, as long as it works under MinGW---especially if support could be provided building with MSVC.) -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] how to stop the top_block and restart signal transmission
Dear all, I'm trying to stop top_block implementing the signal transmission for 5 milliseconds and then restart the signal transmission at the transmitter side, by using the tb.stop() then time.sleep(0.005) to suspend the system for 5 milliseconds then tb.start() to start the signal transmission again. This approach gives an RuntimeError: top_block::start: top block already running or wait() not called after previous stop(). Could you please help me to find what the problem is? I also tried lock() and unlock() which cannot stop the signal transmission implemented in top_block. the code that I use for data transmission is: payload_13bit = '\x01\x01\x01\x01\x01\x0' while(start_flag == 1) msg_13bit = gr.message_from_string(payload_13bit) top_block._ls_msgq.insert_tail(msg_13bit) top_block.stop() time.sleep(0.005) top_block.start() top_block.wait() I will really appreciate any of suggestion on this problem. Thanks, Yan <>___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Hardware list in wiki
On Mon, Feb 21, 2011 at 3:34 PM, Patrick Strasser wrote: > Hello group! > > I wrote some paragraphs about hardware supported by GNU Radio, which I > felt is missing for a long time. > > It's a draft, no links yet, maybe a little low detailed, etc. I just > wrote of what I know is working. If this list is incommplete or > incorrect, please feel free to improve it. English is not my first > language, so please bear with my style and improver where > possible/necessary ;-) > > http://gnuradio.org/redmine/wiki/gnuradio/Hardware > > Comments are welcome! > > Regards > > Patrick > -- > Engineers motto: cheap, good, fast: choose any two > Patrick Strasser > Student of Telemati_cs_, Techn. University Graz, Austria Thanks, Patrick! That's a great start, and I hope others add to it. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FTW IEEE802.11a/g/p OFDM Frame Encoder
Hi Guanbo, You're running the script fine. If you look into the ftw_packet_utils.py script, you'll find that the encoder just prepends a static MAC header - Source Mac is 00:20:d6:01:3c:f1 (a quick web search will show that MAC Addresses which begin with 00:20:d6 belong to BREEZECOM). Similarly you' can find the destination* *MAC and BSSID. The packet will be decoded as a mac-layer service data unit (MSDU). I'm not sure if you've done this already but make sure you set up your wireshark correctly by selecting "802.11" as the "Link-layer header type" in the "Capture Options" to receive 802.11 packets ( http://wiki.wireshark.org/CaptureSetup/WLAN) Let me know how it goes. Thanks, Ashu On 21 February 2011 18:36, Guanbo ZHENG wrote: > The frequency band is correct. Just now, I re-install the repository from > the CGRAN, and tried again using: > sudo python ftw_ofdm_tx.py -f 2.462G -i 5 --regime=8 --payload="Here are > some test messages from WiSeR" -r 1 > So the only question is, I have NOT updated my firmware. I will try that as > well. > > By the way, what does the USRP2 generated packet look like in Wireshark at > another laptop? > > Thanks, > Guanbo > > > On Sun, Feb 20, 2011 at 11:32 PM, Ashutosh Grewal < > ashutoshgre...@gmail.com> wrote: > >> Hi Guanbo, >> >> Thanks for your reply. >> >> I've some good news regarding the FTW OFDM encoder - we were able to >> decode 802.11 a/g packets using kismet/wireshark later in the day. It seems >> that we'll have to set the OFDM coderegime option as 6 or 7 or 8 (I'm not >> sure about 8 but 6 definitely worked). The version information of our test >> system is same as that as what is used here - >> https://www.cgran.org/wiki/ftw80211ofdmtx but our USRP2 HW revision >> number is different and we used the latest firmware. >> >> Regarding BBN USRP2Version - I'll try that and get back to you in case I >> face any difficulties. >> >> Thanks, >> >> Ashu >> >> On 21 February 2011 00:07, Guanbo ZHENG wrote: >> >>> Regarding to BBN, you may try to the high interpolation and decimation >>> rate, as well as proper gain. I was able to decode it on RX (Ubuntu >>> 9.10+gnuradio 3.2.2) >>> >>> For FTW OFDM code, I was able to decode the 802.11g packet as well at >>> Wireshark using an Atheros 802.11a/b/g NIC in monitor mode, where I have >>> saved the TCPdump file. But recently I tried to re-conduct the experiment, I >>> can not get it anymore. :( >>> I am still trying to figure out what problem there is. >>> >>> Guanbo >>> >>> On Sun, Feb 20, 2011 at 3:13 PM, Sankalp Nimbhorkar < >>> sankalp.nimbhor...@gmail.com> wrote: >>> Dear All, We tried using this encoder to transmit frames with USRP2 XCVR 2450 daughter-card on Ubuntu 9.10. We confirmed transmission with a WiSpy dongle. But we cannot receive the frames on a receiver. The receiver we are using is an Atheros 802.11 a/b/g NIC in monitor mode with Mad WiFi driver. We have tried almost all the channels in 802.11a and 802.11g, but could not receive a single packet on receiver. In the project description we came to know that 802.11a frames were successfully received with a Ralinc NIC. Has anyone tried out this project? If so, please tell us the procedure to receive these frames with an NIC? Or at least some way to confirm that the frame was actually received by the NIC? (We even tried Kismet configured to report frames even if CRC check fails). Any help would be appreciated. Thank you. Sankalp Nimbhorkar CSC Graduate Student North Carolina State University ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >>> -- >>> Regards, >>> Brian >>> >>> ___ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> > > > -- > Regards, > Brian > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FTW IEEE802.11a/g/p OFDM Frame Encoder
The frequency band is correct. Just now, I re-install the repository from the CGRAN, and tried again using: sudo python ftw_ofdm_tx.py -f 2.462G -i 5 --regime=8 --payload="Here are some test messages from WiSeR" -r 1 So the only question is, I have NOT updated my firmware. I will try that as well. By the way, what does the USRP2 generated packet look like in Wireshark at another laptop? Thanks, Guanbo On Sun, Feb 20, 2011 at 11:32 PM, Ashutosh Grewal wrote: > Hi Guanbo, > > Thanks for your reply. > > I've some good news regarding the FTW OFDM encoder - we were able to > decode 802.11 a/g packets using kismet/wireshark later in the day. It seems > that we'll have to set the OFDM coderegime option as 6 or 7 or 8 (I'm not > sure about 8 but 6 definitely worked). The version information of our test > system is same as that as what is used here - > https://www.cgran.org/wiki/ftw80211ofdmtx but our USRP2 HW revision number > is different and we used the latest firmware. > > Regarding BBN USRP2Version - I'll try that and get back to you in case I > face any difficulties. > > Thanks, > > Ashu > > On 21 February 2011 00:07, Guanbo ZHENG wrote: > >> Regarding to BBN, you may try to the high interpolation and decimation >> rate, as well as proper gain. I was able to decode it on RX (Ubuntu >> 9.10+gnuradio 3.2.2) >> >> For FTW OFDM code, I was able to decode the 802.11g packet as well at >> Wireshark using an Atheros 802.11a/b/g NIC in monitor mode, where I have >> saved the TCPdump file. But recently I tried to re-conduct the experiment, I >> can not get it anymore. :( >> I am still trying to figure out what problem there is. >> >> Guanbo >> >> On Sun, Feb 20, 2011 at 3:13 PM, Sankalp Nimbhorkar < >> sankalp.nimbhor...@gmail.com> wrote: >> >>> Dear All, >>>We tried using this encoder to transmit frames with USRP2 XCVR >>> 2450 daughter-card on Ubuntu 9.10. We confirmed transmission with a WiSpy >>> dongle. But we cannot receive the frames on a receiver. The receiver we are >>> using is an Atheros 802.11 a/b/g NIC in monitor mode with Mad WiFi driver. >>> We have tried almost all the channels in 802.11a and 802.11g, but could not >>> receive a single packet on receiver. In the project description we came to >>> know that 802.11a frames were successfully received with a Ralinc NIC. Has >>> anyone tried out this project? If so, please tell us the procedure to >>> receive these frames with an NIC? Or at least some way to confirm that the >>> frame was actually received by the NIC? (We even tried Kismet configured to >>> report frames even if CRC check fails). Any help would be appreciated. >>> >>> Thank you. >>> Sankalp Nimbhorkar >>> CSC Graduate Student >>> North Carolina State University >>> >>> ___ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> >> >> -- >> Regards, >> Brian >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > -- Regards, Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FTW IEEE802.11a/g/p OFDM Frame Encoder
Yup. Even regime 8 works fine. Haven't checked the loss rate, though. It seems, the Atheros NIC will not receive any packets below 18Mbps. We tried it for channel 44 and channel 6. It works fine. Thanks Sankalp On Mon, Feb 21, 2011 at 1:11 AM, Manav Seth wrote: > I have tried this and I was able to receive frames using an Atheros NIC in > monitor mode.Specifically the card was a AR5413 Atheros card. > > Did you check that the receiver NIC is on the same channel as the > transmitter? The script given on the FTW page is using channel 1. > > Thanks, > Manav > > On Sun, Feb 20, 2011 at 10:07 PM, Guanbo ZHENG wrote: > >> Regarding to BBN, you may try to the high interpolation and decimation >> rate, as well as proper gain. I was able to decode it on RX (Ubuntu >> 9.10+gnuradio 3.2.2) >> >> For FTW OFDM code, I was able to decode the 802.11g packet as well at >> Wireshark using an Atheros 802.11a/b/g NIC in monitor mode, where I have >> saved the TCPdump file. But recently I tried to re-conduct the experiment, I >> can not get it anymore. :( >> I am still trying to figure out what problem there is. >> >> Guanbo >> >> On Sun, Feb 20, 2011 at 3:13 PM, Sankalp Nimbhorkar < >> sankalp.nimbhor...@gmail.com> wrote: >> >>> Dear All, >>>We tried using this encoder to transmit frames with USRP2 XCVR >>> 2450 daughter-card on Ubuntu 9.10. We confirmed transmission with a WiSpy >>> dongle. But we cannot receive the frames on a receiver. The receiver we are >>> using is an Atheros 802.11 a/b/g NIC in monitor mode with Mad WiFi driver. >>> We have tried almost all the channels in 802.11a and 802.11g, but could not >>> receive a single packet on receiver. In the project description we came to >>> know that 802.11a frames were successfully received with a Ralinc NIC. Has >>> anyone tried out this project? If so, please tell us the procedure to >>> receive these frames with an NIC? Or at least some way to confirm that the >>> frame was actually received by the NIC? (We even tried Kismet configured to >>> report frames even if CRC check fails). Any help would be appreciated. >>> >>> Thank you. >>> Sankalp Nimbhorkar >>> CSC Graduate Student >>> North Carolina State University >>> >>> ___ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> >> >> -- >> Regards, >> Brian >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > -- Sankalp Nimbhorkar CSC Graduate Student North Carolina State University ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Hardware list in wiki
Hello group! I wrote some paragraphs about hardware supported by GNU Radio, which I felt is missing for a long time. It's a draft, no links yet, maybe a little low detailed, etc. I just wrote of what I know is working. If this list is incommplete or incorrect, please feel free to improve it. English is not my first language, so please bear with my style and improver where possible/necessary ;-) http://gnuradio.org/redmine/wiki/gnuradio/Hardware Comments are welcome! Regards Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Looking for 2-TX 2-RX example code for USRP1 and gnuradio 3.2.x.x
Hello, I'm new to GNU Radio but very willing to learn, experiment, and write some python, C++, and Verilog/FPGA code. My system consists of 2 USRP1 boxes, with gnuradio 3.2.x.x installed on two host machines. I've gone thru the basic tutorials and benchmark_rx/tx and it all works. Now I want to build a 2-TX 2-RX system with this setup as follows : - the TX host drives the TX USPR1 which has two daughtercards, each driving one antenna - the RX host connects to the RX USRP1 which has two daughtercards, each connecting to one antenna Does anyone know of example python code for doing this ? thanks, Nick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DB EEPROM location 0x20
On 02/20/2011 11:29 PM, Brett L. Trotter wrote: > The card I'm looking at (an LFRX variant) has the proper checksum in > 0x1F (0x17), but then byte 0x20 has 0x04 with the remaining data 0xFF > > I previously thought I understood 0x20 began the region where we could > do what we wanted, but I'm now not so sure. If I was going to store some > custom data, where does that region begin and what is the significance > of the 0x04 in 0x20? > > This may be helpful http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/host/lib/usrp/dboard_eeprom.cpp The only thing thats actually used is the checksum, and IDs. And the rest is free to use. -josh > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help : using different hardware by replacing USRP hardware
thanks andrea for your really beautiful and helpful guide ... thanks again u and all. andrea montefusco-3 wrote: > > On 10/02/2010 06:36 PM, ton ph wrote: >>As i was exploring through the gnuradio code/blocks, I was thinking >> what i have to do,if i want to use another hardware by replacing USRP. I >> was thinking to to disable usrp block while configuring and also make >> changes to the makefiles. Please someone guide me if my approach is >> right or wrong.If this is right how can i replace the usrp libraries >> with my own hardware libraries. >> please do tolerate if i have ask any out of track question. > > I did that, writing a module to use Microtelecom Perseus > > http://www.microtelecom.it/perseus/ > > instead of USRP. Give a look at > > http://github.com/amontefusco/gnuradio-amontefusco/tree/perseus > > *am* > > - > Andrea Montefusco iw0hdvhttp://www.montefusco.com > tel: +393356992791 fax: +390623318709 > - > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://old.nabble.com/Help-%3A-using-different-hardware-by-replacing-USRP-hardware-tp29866913p30978912.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help : using different hardware by replacing USRP hardware
thanks tom for your valuable kind response. Tom Rondeau wrote: > > On Sat, Oct 2, 2010 at 12:36 PM, ton ph wrote: >> hi everyone, >> As i was exploring through the gnuradio code/blocks, I was thinking >> what i >> have to do,if i want to use another hardware by replacing USRP. I was >> thinking to to disable usrp block while configuring and also make changes >> to >> the makefiles. Please someone guide me if my approach is right or >> wrong.If >> this is right how can i replace the usrp libraries with my own hardware >> libraries. >> please do tolerate if i have ask any out of track question. >> Thanks > > You shouldn't need to disable gr-usrp or usrp during configuration to > add another type of hardware. Just add you're own and compile it along > with everything else. > > Tom > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://old.nabble.com/Help-%3A-using-different-hardware-by-replacing-USRP-hardware-tp29866913p30978847.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] The 'next' branch
Hey group, As we discussed on our call last week, we are trying to move ahead to getting GNU Radio 3.4 released. To do this, we have a big shift to make, which is making our current 'next' branch into the 'master' branch and cutting a new 'next' from there. But before we do this, Johnathan and I would really like to make sure that 'next' is ready to become or main, master branch. Mostly because of the introduction of UHD, we have seen more use of the next branch than I think we would have otherwise. That makes me feel more comfortable using it. However, we are concerned that we have not stress-tested it enough. I know we recently found a problem in the howto-write-a-block code (which actually still needs some cleanup, thanks Mike C.), and so we would like to know if there are any further problems with the branch. I would ask all of you who can to start either using or at least testing out the 'next' branch now and provide us with feedback and bug reports. Thanks! Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] guide : help in knowing the working of the USRP when we provide a frequency to capture in the usrp_rx_cfile.py
Hi guys , I am trying to know the way how usrp processes when i provide frequency to the usrp_rx_cfile.py. Please someone eleborate me where i am actually providing my frequency. Where my frequency parameter is actually been fixed in which part of the usrp .. example : Daughterboard , ADC etc. Thanks. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
