RE: [Discuss-gnuradio] Changing external reference frequency with USRP2...
Thanks Matt I tried to change to get the external reference frequency to be 36 MHz, by setting B to 50 (i.e. 0x32) and R to 36 (i.e. 0x24). To do this, I modified lines 43 and 85 respectively to the following: ad9510_write_reg(0x06, 0x32); ad9510_write_reg(0x0C, 0x24); However, when I rebuilt the firmware (txrx.bin) and wrote it to the SD card, I was no longer able to see an OFDM signal I had been transmitting from another SDR at 2.4 GHz. This occurred both when I had configured the receiving SDR to lock onto the 36 MHz reference (device->config_mimo(usrp2::MC_WE_LOCK_TO_SMA)) And when I configured the receiving SDR to use its internal reference (device->config_mimo(usrp2::MC_WE_DONT_LOCK)) Have I done something wrong in my modifications? If so, can you please suggest what I am doing wrong? According to the AD9510 datasheet I believe my changes should have been correct. Best Regards Ian. -Original Message- From: Matt Ettus [mailto:m...@ettus.com] Sent: Saturday, 14 August 2010 2:15 AM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Changing external reference frequency with USRP2... gnuradio/usrp2/firmware/lib/clocks.c, starting at line 40. You probably want to read the AD9510 datasheet to help with selecting values. Matt On 08/13/2010 12:34 AM, Ian Holland wrote: > Hi > > I have read on the FAQ that is possible to change the external reference > frequency for the USRP2 from 10 MHz to another value simply by changing > one line in the firmware. > > However, I have as yet been unable to locate the actual source file in > which I need to make this change, and what the name of this variable is. > Could someone please let me know? > > Many Thanks > > Ian. > > > > This message is intended only for the use of the intended recipient(s) > If you are not an intended recipient, you are hereby notified that any > use, dissemination, disclosure or copying of this communication is > strictly prohibited. If you have received this communication in error > please destroy all copies of this message and its attachments and notify > the sender immediately > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio This message is intended only for the use of the intended recipient(s) If you are not an intended recipient, you are hereby notified that any use, dissemination, disclosure or copying of this communication is strictly prohibited. If you have received this communication in error please destroy all copies of this message and its attachments and notify the sender immediately ___ 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] how to get dqpsk2 block?
It seems I don't have all DPSK2 blocks installed. Where can i get them? -- View this message in context: http://old.nabble.com/how-to-get-dqpsk2-block--tp29448241p29448241.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] how to get dqpsk2 block?
On Mon, Aug 16, 2010 at 5:39 AM, Thunder87 wrote: > > It seems I don't have all DPSK2 blocks installed. Where can i get them? You need to be running the code from git; these blocks are not available through the tarball releases. If you have the source from git, you should have in gnuradio-examples/python/digital a version of the benchmarking scripts with a 2 on them (receive_path2.py, benchmark_tx2.py, etc.). Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Helper script to automatically add blocks
Hi list, since pretty much all of my GNU Radio'ing consists of dealing with out-of-tree modules I started a script to modify those. In the current state, it can add blocks to an existing out-of-tree module. It will attempt to guess a lot of stuff and then add skeleton code for the blocks and the QA code and edit the makefiles accordingly. I will still have to add some blocks to my modules before it actually saves *me* some time, but I just got pretty annoyed at editing all the makefiles by hand, and always forgetting one line somewhere. Following George's request, I made it available on CGRAN. I couldn't resist calling it 'devtools' and making it a project for all kinds of tools, scripts etc. which help developing. Being an optimist, I'm assuming there might be others who've made scripts, vim/emacs/Eclipse-plugins etc. and are just waiting for a platform to publish these. Grab infos and the code at https://www.cgran.org/wiki/devtools Disclaimer: This script actually edits your files. It might cause damage, and take no responsibility. Use at your own risk. I only want to know about it if it's in form of a bug report. Cheers, MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-3790 Fax: +49 721 608-6071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpohpJqmT33x.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Suggested reading order
On Sun, Aug 15, 2010 at 11:13 PM, Tom Rondeau wrote: > > Kunal, > > This is really good. Would you be up for putting this on the Wiki page > for future reference? > > Thanks! > Tom > Thanks, Tom! Sure, I think this may be useful to enough people to go up on the wiki. I will clean it up and post it as soon as I can. Since it's written for programmer-specific background, I guess it would be better if it's posted as a separate page, rather than changing the general SuggestedReading page itself. Maybe a "SuggestedReadingOrder" of "IfYourBackgroundIsX" page, where others can add advice for people coming from other backgrounds? Kunal ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UCLA ZigBee PHY 64 chip-sequences
Hi everyone, I use the UCLA ZigBee PHYsical Layer with gnuradio and USRP. And now I try to increase the number of chips per symbol within the Symbol-to-chips-table from 32 chips per 4 bit symbol to 64 chips. I adopted the three files - "ucla_ieee802_15_4_packet_sink.cc" - "ucla_ieee802_15_4_packet_sink.h" and - "ucla_symbols_to_chips_bi.cc" . I also generated a 64 bit Symbol_Table, CHIP_MAPPING respectively using the OQPSK -> MSK encoding as described in the papaer: "GNU Radio 802.15.4 En- and Decoding" But still it is not working. I assume that there might be some other parts of the code, which depend on whether the chip-sequences are 32 chips or 64 chips and I was wondering if you might be able to give me a hint where to look!? Even after going through the files from UCLA, i couldn't figure out where this might be!? Help would be highly appreciated! Thanks a lot for your help, Best regards, Björn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Changing external reference frequency with USRP2...
On 08/16/2010 12:21 AM, Ian Holland wrote: Thanks Matt I tried to change to get the external reference frequency to be 36 MHz, by setting B to 50 (i.e. 0x32) and R to 36 (i.e. 0x24). To do this, I modified lines 43 and 85 respectively to the following: ad9510_write_reg(0x06, 0x32); ad9510_write_reg(0x0C, 0x24); If you set R to 36 then your compare frequency is 1 MHz. A setting of B = 50 means you are trying to lock at 50 MHz, which won't work. The crystal is at 100 MHz, so you need to use B=100. This will cause you to be way off in frequency (maybe 100 to 150 ppm). It should still function, however. However, when I rebuilt the firmware (txrx.bin) and wrote it to the SD card, I was no longer able to see an OFDM signal I had been transmitting from another SDR at 2.4 GHz. This occurred both when I had configured the receiving SDR to lock onto the 36 MHz reference (device->config_mimo(usrp2::MC_WE_LOCK_TO_SMA)) And when I configured the receiving SDR to use its internal reference (device->config_mimo(usrp2::MC_WE_DONT_LOCK)) Have I done something wrong in my modifications? If so, can you please suggest what I am doing wrong? According to the AD9510 datasheet I believe my changes should have been correct. If it doesn't work with either setting then it is likely your firmware is bad. Check to make sure you are using a good Microblaze compiler. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP spike
Brain, Thanks for the reply. We have tried terminating the antenna input, the spike still shows up. We also tried tuning a bit away from the signal of interest and mixing the signal of interest to baseband but it doesn't seem to help, the spike just follows the signal all over. Thanks, Naveen From: Brian Padalino To: naveen nischal Cc: discuss-gnuradio@gnu.org Sent: Thu, 12 August, 2010 12:36:09 PM Subject: Re: [Discuss-gnuradio] USRP spike On Thu, Aug 12, 2010 at 1:56 PM, naveen nischal wrote: > > > Hi All, > > > > We have been using the USRP1 with the WBX card on it to communicate with > > the AO-51 satellite. We are expecting to hear from the satellite using > > an Fm Receiver GRC at 435.300 MHz but don't receive anything as yet, we > > are pretty sure about our antenna setup and the GRC are right. The > > problem though is a spurious spike of about 17db which appears at > > whatever center frequency we tune to in the spectrum. we think that this > > might be the problem as that might be jamming the signal which was > > supposed be about the same db level. The point of notice for us is that > > this spike is always there even without the antenna connected. the fft > > is directly the output of the usrp source in the grc so, we are > > presuming that the problem might be in the usrp motherboard . > > Attached is the screenshots FM receiver spectrum. Did anyone have this > > problem? How can we fix it?. Terminate your antenna input. Does it still show up? Chances are you have a DC offset at the ADC that needs to be removed. This will happen if the DDC in the FPGA isn't required to resolve any frequency offset due to the limitations of the LO in the RF chain. One way to mitigate this is to tune a little bit away from your signal of interest, then mix your signal of interest to baseband, and filter off the DC component. > Thanks, > Naveen Hope this helps, and good luck. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP spike
Hi Naveen, On Mon, Aug 16, 2010 at 2:05 PM, naveen nischal wrote: > > Brain, > Thanks for the reply. We have tried terminating the antenna input, the spike > still shows up. We also tried tuning a bit away from the signal of interest > and mixing the signal of interest to baseband but it doesn't seem to help, > the spike just follows the signal all over. I expected the DC offset to still show up after terminating the antenna input, but I don't understand how the spike always follows the signal unless something is actually there. >From your example, you have 435.300MHz as your center frequency which "appears" to have a large signal present. If you tune to 437.300MHz, do you see a strong signal at 435.300MHz still - or does it "follow" your center tuning to 437.300MHz and 435.300MHz is "in the noise floor"? > Thanks, > Naveen Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-trellis: convenc and viterbi with own mapper/de-mapper
Hi all, I am trying to use the convolutional encoder and Viterbi provided by the gr-trellis class within another environment. I have my own mapper and de-mapper blocks which I want to use. So I tried to use the feed the viterbi_combined with this arguments: va_combined = trellis.viterbi_combined_fb(fo,nsymbols,0,-1,1,[-1,1],trellis.TRELLIS_EUCLIDEAN) My de-mapper outputs soft bits between -1 and +1. Here is an example output of my test script: data: [0, 1, 1, 0, 0] encoded:(0, 3, 2, 2, 0) unpacked: (0, 0, 1, 1, 1, 0, 1, 0, 0, 0) modulated: ((1+0j), (1+0j), (-1+0j), (-1+0j), (-1+0j), (1+0j), (-1+0j), (1+0j), (1+0j), (1+0j)) demodulated:(-1.0, -1.0, 1.0, 1.0, 1.0, -1.0, 1.0, -1.0, -1.0, -1.0) decoded:(0, 0, 1, 0, 0, 1, 0, 1, 0, 1) Another thing I don't understand is why the decoder outputs 10 values instead of 5. I would be glad if someone told me what I am doing wrong. Regards, Jonas ___ 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 09:49:21AM +0200, Moritz Fischer wrote: > 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 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. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP spike
Brain, Sorry my bad...your earlier technique worked. Thanks much Regards, Naveen From: Brian Padalino To: naveen nischal Cc: discuss-gnuradio@gnu.org Sent: Mon, 16 August, 2010 12:16:57 PM Subject: Re: [Discuss-gnuradio] USRP spike Hi Naveen, On Mon, Aug 16, 2010 at 2:05 PM, naveen nischal wrote: > > Brain, > Thanks for the reply. We have tried terminating the antenna input, the spike > still shows up. We also tried tuning a bit away from the signal of interest > and mixing the signal of interest to baseband but it doesn't seem to help, > the spike just follows the signal all over. I expected the DC offset to still show up after terminating the antenna input, but I don't understand how the spike always follows the signal unless something is actually there. From your example, you have 435.300MHz as your center frequency which "appears" to have a large signal present. If you tune to 437.300MHz, do you see a strong signal at 435.300MHz still - or does it "follow" your center tuning to 437.300MHz and 435.300MHz is "in the noise floor"? > Thanks, > Naveen Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP spike
Hi Naveen, On Mon, Aug 16, 2010 at 6:01 PM, naveen nischal wrote: > > Brain, > Sorry my bad...your earlier technique worked. Thanks much > Regards, > Naveen Glad you were able to get it figured out. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Changing external reference frequency with USRP2...
Hi Matt I will try this, though given P = 2, I was under the impression the resulting VCO frequency should have been 1 MHz * P * B = 100 MHz when I have B = 50. At least, that is what the equation in the datasheet suggests. Regards Ian. -Original Message- From: Matt Ettus [mailto:m...@ettus.com] Sent: Tuesday, 17 August 2010 2:15 AM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Changing external reference frequency with USRP2... On 08/16/2010 12:21 AM, Ian Holland wrote: > Thanks Matt > > I tried to change to get the external reference frequency to be 36 > MHz, by setting B to 50 (i.e. 0x32) and R to 36 (i.e. 0x24). To do > this, I modified lines 43 and 85 respectively to the following: > > ad9510_write_reg(0x06, 0x32); ad9510_write_reg(0x0C, 0x24); If you set R to 36 then your compare frequency is 1 MHz. A setting of B = 50 means you are trying to lock at 50 MHz, which won't work. The crystal is at 100 MHz, so you need to use B=100. This will cause you to be way off in frequency (maybe 100 to 150 ppm). It should still function, however. > However, when I rebuilt the firmware (txrx.bin) and wrote it to the > SD card, I was no longer able to see an OFDM signal I had been > transmitting from another SDR at 2.4 GHz. This occurred both when I > had configured the receiving SDR to lock onto the 36 MHz reference > (device->config_mimo(usrp2::MC_WE_LOCK_TO_SMA)) And when I configured > the receiving SDR to use its internal reference > (device->config_mimo(usrp2::MC_WE_DONT_LOCK)) > > Have I done something wrong in my modifications? If so, can you > please suggest what I am doing wrong? According to the AD9510 > datasheet I believe my changes should have been correct. If it doesn't work with either setting then it is likely your firmware is bad. Check to make sure you are using a good Microblaze compiler. Matt This message is intended only for the use of the intended recipient(s) If you are not an intended recipient, you are hereby notified that any use, dissemination, disclosure or copying of this communication is strictly prohibited. If you have received this communication in error please destroy all copies of this message and its attachments and notify the sender immediately ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Changing external reference frequency with USRP2...
Hi Matt Further to below, I tried your suggestion, and still it didn't work. In fact, I have now found that the only thing that does work now is to use a pre-compiled binary that I downloaded for txrx.bin (since recompiling with the original gnuradio source code didn't work). This suggests indeed the problem is either the Microblaze tools I have (since recompiling with the original gnuradio source code didn't work) or that the version of source I had (from March 21, 2010) was corrupt to begin with. However, I even tried updating to the latest git via git pull, and tried to remake using the original clock settings. Still, it doesn't work. Hence I suspect the microblaze tools as you suggested. I got the Microblaze tools from the gnuradio website. I would have though these should work fine, but perhaps not. Is there another source you can suggest? Best Regards Ian. -Original Message- From: Ian Holland Sent: Tuesday, 17 August 2010 9:24 AM To: 'Matt Ettus' Cc: discuss-gnuradio@gnu.org Subject: RE: [Discuss-gnuradio] Changing external reference frequency with USRP2... Hi Matt I will try this, though given P = 2, I was under the impression the resulting VCO frequency should have been 1 MHz * P * B = 100 MHz when I have B = 50. At least, that is what the equation in the datasheet suggests. Regards Ian. -Original Message- From: Matt Ettus [mailto:m...@ettus.com] Sent: Tuesday, 17 August 2010 2:15 AM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Changing external reference frequency with USRP2... On 08/16/2010 12:21 AM, Ian Holland wrote: > Thanks Matt > > I tried to change to get the external reference frequency to be 36 > MHz, by setting B to 50 (i.e. 0x32) and R to 36 (i.e. 0x24). To do > this, I modified lines 43 and 85 respectively to the following: > > ad9510_write_reg(0x06, 0x32); ad9510_write_reg(0x0C, 0x24); If you set R to 36 then your compare frequency is 1 MHz. A setting of B = 50 means you are trying to lock at 50 MHz, which won't work. The crystal is at 100 MHz, so you need to use B=100. This will cause you to be way off in frequency (maybe 100 to 150 ppm). It should still function, however. > However, when I rebuilt the firmware (txrx.bin) and wrote it to the > SD card, I was no longer able to see an OFDM signal I had been > transmitting from another SDR at 2.4 GHz. This occurred both when I > had configured the receiving SDR to lock onto the 36 MHz reference > (device->config_mimo(usrp2::MC_WE_LOCK_TO_SMA)) And when I configured > the receiving SDR to use its internal reference > (device->config_mimo(usrp2::MC_WE_DONT_LOCK)) > > Have I done something wrong in my modifications? If so, can you > please suggest what I am doing wrong? According to the AD9510 > datasheet I believe my changes should have been correct. If it doesn't work with either setting then it is likely your firmware is bad. Check to make sure you are using a good Microblaze compiler. Matt This message is intended only for the use of the intended recipient(s) If you are not an intended recipient, you are hereby notified that any use, dissemination, disclosure or copying of this communication is strictly prohibited. If you have received this communication in error please destroy all copies of this message and its attachments and notify the sender immediately ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP spike
On 08/16/2010 10:14 PM, Vincent W wrote: > On 08/12/2010 02:36 PM, Brian Padalino wrote: > >> On Thu, Aug 12, 2010 at 1:56 PM, naveen nischal >> wrote: >> problem though is a spurious spike of about 17db which appears at whatever center frequency we tune to in the spectrum. we think that this might be the problem as that might be jamming the signal which was supposed be about the same db level. The point of notice for us is that this spike is always there even without the antenna connected. >> Terminate your antenna input. Does it still show up? >> >> Chances are you have a DC offset at the ADC that needs to be removed. >> This will happen if the DDC in the FPGA isn't required to resolve any >> frequency offset due to the limitations of the LO in the RF chain. >> >> One way to mitigate this is to tune a little bit away from your signal >> of interest, then mix your signal of interest to baseband, and filter >> off the DC component. >> >> >>> Thanks, >>> Naveen >>> > Hi, > > I think I am encountering a similar problem, and would very much appreciate > your > feedback, bearing in mind have an experimental physics background. I'm using > the > WBX board on the USRP2, and notice unusual signal spikes when I tune to a > specific frequency. In some cases, there are multiple spikes that show > symmetry > about a given frequency, but disappear when tuning to that frequency. In > others, > there is a single spike that seems to follow the centre signal. > > I've included some screenshots of the output from usrp2_fft. The first set of > pictures, dealing with 99MHz, 100MHz, and 101MHz, illustrate the first kind of > spikes: > > - If I tune into 99MHz, I see large spikes at 96MHz, 100MHz, and a > small spike > at 104MHz (bracketed in black). > > - If I then tune to 100MHz, I see a small spike at 100MHz (and I'm not > sure if > this is an artifact), but outside of that, everything looks very reasonable > and > is what I expect. > > - Finally, if I tune into 101MHz, I see large spikes at 100MHz and > 104MHz, > along with a small spike at 96MHz. > > The position of the anomalous spikes is the same when tuning to 99MHz and > 101MHz, but their magnitudes seem to be mirrored about 100MHz. I think this > has > something to do with the DDC; at 99MHz, it's negative, at 101MHz it's > positive, > but I'm not sure how this helps. > > The second type of problem is very similar to the one previously discussed in > this thread. > > If I tune into 1.134GHz, I see a spike at the centre frequency, of 1.134GHz > and > another spike at 1.136GHz, both around 1.135GHz. However, when I tune into > 1.135GHz, the two spikes disappear, to be replaced by a single spike at > 1.135GHz. > > I'm not quite sure how to proceed, or what to reference. It certainly seems > that > these spikes are spurious, and I'd love to get rid of them, but I'm not sure > how. > > Regards, > > Vincent > For the 100MHz signals, what does your receive chain look like? Keep in mind that the FM radio band exists between 88MHz and 108MHz, so if you're trying to do "off air" experiments, you'll run into trouble. If you're not doing "off air" experiments, what kind of shielding do you have for your equipment, to protect it from the FM broadcasting band? -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD Announcement - August 16th 2010
Hello list, I have pushed up new host code to the repo, and uploaded new images. So what new since the last announcement? --- 1) Subdev specification: A daughterboard may have more than one rf pathway on it. These pathways, combined with tuning and gain elements make up what is called a subdevice. The basic RX has 3 subdevices: 2 real and 1 complex. http://www.ettus.com/uhd_docs/manual/html/dboards.html#basic-rx-and-and-lfrx A subdevice specification allows you to specify which subdevices you want to use, and may be specified with a markup string http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1subdev__spec__t.html The subdevice parameter is already part of the gr-uhd grc wrapper blocks. There is not much advantage in messing with subdevices in the USRP2, but when USRP1 support comes (multiple daughterboard and dual DDC) this will become very important. --- 2) Async messages: Transmit related errors (such as an underflow) can now be reported back to the host. One can simply read async messages out of the queue and act accordingly. The messages carry an event code and the timestamp of the event. See http://www.ettus.com/uhd_docs/doxygen/html/structuhd_1_1async__metadata__t.html http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1device.html#afe4ec312d71c669fbd86ce9a7d350605 --- 3) DBSRX: DBSRX support is now available (it has been mentioned a few times but not formally announced). The UHD-based modification instructions can be found here: http://www.ettus.com/uhd_docs/manual/html/dboards.html#daughterboard-modifications --- 4) Image packages: The fine details are still being worked out, but the idea is to give users installable packages with pre-compiled firmware and fpga images. The installer will place the images in the uhd images directory, and the uhd will find the images at runtime. This will be useful for the coming UHD-USRP1 support. http://www.ettus.com/downloads/uhd_images/ For USRP2, one would need to download and upack the tarball/zip and use the card burner utility to load the images onto the sd card. Currently we offer zips, tarballs, debs, rpms. Eventually, Windows NSIS, and Macintosh will be built. The possibilities can be found here: http://www.paraview.org/Wiki/CMake:CPackPackageGenerators -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Changing external reference frequency with USRP2...
Please disregard my last. I must have got something wrong in my testing. It now compiles, but it seems I need to use txrx_xcvr.bin instead of txrx.bin with the latest git trunk. Please correct me if this is wrong (note I have XCVR2450 as my daughterboard). Nonetheless, I still seem to get a time varying frequency offset between a transmitted and received BPSK waveform, when using the same local oscillator of 36 MHz at each end. In fact, about every million samples, this frequency offset disappears, then comes back getting larger, then smaller and disappears again about 1 million samples later. Is this expected when using a reference different to 10 MHz? When I have used two USRP2s both locked to a 10 MHz reference, I never saw this problem. -Original Message- From: Ian Holland Sent: Tuesday, 17 August 2010 11:33 AM To: Ian Holland; Matt Ettus Cc: discuss-gnuradio@gnu.org Subject: RE: [Discuss-gnuradio] Changing external reference frequency with USRP2... Hi Matt Further to below, I tried your suggestion, and still it didn't work. In fact, I have now found that the only thing that does work now is to use a pre-compiled binary that I downloaded for txrx.bin (since recompiling with the original gnuradio source code didn't work). This suggests indeed the problem is either the Microblaze tools I have (since recompiling with the original gnuradio source code didn't work) or that the version of source I had (from March 21, 2010) was corrupt to begin with. However, I even tried updating to the latest git via git pull, and tried to remake using the original clock settings. Still, it doesn't work. Hence I suspect the microblaze tools as you suggested. I got the Microblaze tools from the gnuradio website. I would have though these should work fine, but perhaps not. Is there another source you can suggest? Best Regards Ian. -Original Message- From: Ian Holland Sent: Tuesday, 17 August 2010 9:24 AM To: 'Matt Ettus' Cc: discuss-gnuradio@gnu.org Subject: RE: [Discuss-gnuradio] Changing external reference frequency with USRP2... Hi Matt I will try this, though given P = 2, I was under the impression the resulting VCO frequency should have been 1 MHz * P * B = 100 MHz when I have B = 50. At least, that is what the equation in the datasheet suggests. Regards Ian. -Original Message- From: Matt Ettus [mailto:m...@ettus.com] Sent: Tuesday, 17 August 2010 2:15 AM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Changing external reference frequency with USRP2... On 08/16/2010 12:21 AM, Ian Holland wrote: > Thanks Matt > > I tried to change to get the external reference frequency to be 36 > MHz, by setting B to 50 (i.e. 0x32) and R to 36 (i.e. 0x24). To do > this, I modified lines 43 and 85 respectively to the following: > > ad9510_write_reg(0x06, 0x32); ad9510_write_reg(0x0C, 0x24); If you set R to 36 then your compare frequency is 1 MHz. A setting of B = 50 means you are trying to lock at 50 MHz, which won't work. The crystal is at 100 MHz, so you need to use B=100. This will cause you to be way off in frequency (maybe 100 to 150 ppm). It should still function, however. > However, when I rebuilt the firmware (txrx.bin) and wrote it to the > SD card, I was no longer able to see an OFDM signal I had been > transmitting from another SDR at 2.4 GHz. This occurred both when I > had configured the receiving SDR to lock onto the 36 MHz reference > (device->config_mimo(usrp2::MC_WE_LOCK_TO_SMA)) And when I configured > the receiving SDR to use its internal reference > (device->config_mimo(usrp2::MC_WE_DONT_LOCK)) > > Have I done something wrong in my modifications? If so, can you > please suggest what I am doing wrong? According to the AD9510 > datasheet I believe my changes should have been correct. If it doesn't work with either setting then it is likely your firmware is bad. Check to make sure you are using a good Microblaze compiler. Matt This message is intended only for the use of the intended recipient(s) If you are not an intended recipient, you are hereby notified that any use, dissemination, disclosure or copying of this communication is strictly prohibited. If you have received this communication in error please destroy all copies of this message and its attachments and notify the sender immediately ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: gr-trellis: convenc and viterbi with own mapper/de-mapper
On Mon, 16 Aug 2010, Jonas M. Börner wrote: Hi all, I am trying to use the convolutional encoder and Viterbi provided by the gr-trellis class within another environment. I have my own mapper and de-mapper blocks which I want to use. So I tried to use the feed the viterbi_combined with this arguments: va_combined = trellis.viterbi_combined_fb(fo,nsymbols,0,-1,1,[-1,1],trellis.TRELLIS_EUCLIDEAN) My de-mapper outputs soft bits between -1 and +1. Here is an example output of my test script: data: [0, 1, 1, 0, 0] encoded:(0, 3, 2, 2, 0) unpacked: (0, 0, 1, 1, 1, 0, 1, 0, 0, 0) modulated: ((1+0j), (1+0j), (-1+0j), (-1+0j), (-1+0j), (1+0j), (-1+0j), (1+0j), (1+0j), (1+0j)) demodulated:(-1.0, -1.0, 1.0, 1.0, 1.0, -1.0, 1.0, -1.0, -1.0, -1.0) decoded:(0, 0, 1, 0, 0, 1, 0, 1, 0, 1) Another thing I don't understand is why the decoder outputs 10 values instead of 5. I would be glad if someone told me what I am doing wrong. Regards, Jonas If I remember correctly, when you start pushing symbols through the trellis, it has some zero values before the input and some zero values after your last symbol pushed into the trellis. I think this is typically the length of your trellis. So at some point you will have to truncate the trellis output. Any one else care to comment? --Colby Boyer___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: gr-trellis: convenc and viterbi with own mapper/de-mapper
Hi Colby, thanks for your reply. My trellis is created like this: t=trellis.fsm(1,2,[91,121]) The constraint length is 7 so it doesn't look like it was connected to a trellis-specific thing. As I remember from the gr-trellis examples they didn't do any truncating there before comparing the source with the destination for error calculation... Regards, Jonas Am 17.08.2010 um 08:10 schrieb colby.bo...@gmail.com: > On Mon, 16 Aug 2010, Jonas M. Börner wrote: > >> Hi all, >> >> I am trying to use the convolutional encoder and Viterbi provided by the >> gr-trellis class within another environment. I have my own mapper and >> de-mapper blocks which I want to use. So I tried to use the feed the >> viterbi_combined with this arguments: >> >> va_combined = >> trellis.viterbi_combined_fb(fo,nsymbols,0,-1,1,[-1,1],trellis.TRELLIS_EUCLIDEAN) >> >> My de-mapper outputs soft bits between -1 and +1. Here is an example output >> of my test script: >> >> data:[0, 1, 1, 0, 0] >> encoded: (0, 3, 2, 2, 0) >> unpacked:(0, 0, 1, 1, 1, 0, 1, 0, 0, 0) >> modulated: ((1+0j), (1+0j), (-1+0j), (-1+0j), (-1+0j), (1+0j), (-1+0j), >> (1+0j), (1+0j), (1+0j)) >> demodulated: (-1.0, -1.0, 1.0, 1.0, 1.0, -1.0, 1.0, -1.0, -1.0, -1.0) >> decoded: (0, 0, 1, 0, 0, 1, 0, 1, 0, 1) >> >> Another thing I don't understand is why the decoder outputs 10 values >> instead of 5. I would be glad if someone told me what I am doing wrong. >> >> Regards, >> Jonas >> > > If I remember correctly, when you start pushing symbols through the trellis, > it has some zero values before the input and some zero values after your last > symbol pushed into the trellis. I think this is typically the length of your > trellis. So at some point you will have to truncate the trellis output. > > Any one else care to comment? > > --Colby Boyer ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: gr-trellis: convenc and viterbi with own mapper/de-mapper
On Tue, 17 Aug 2010, "Jonas M. Börner" wrote: Hi Colby, thanks for your reply. My trellis is created like this: t=trellis.fsm(1,2,[91,121]) The constraint length is 7 so it doesn't look like it was connected to a trellis-specific thing. As I remember from the gr-trellis examples they didn't do any truncating there before comparing the source with the destination for error calculation... Regards, Jonas Am 17.08.2010 um 08:10 schrieb colby.bo...@gmail.com: On Mon, 16 Aug 2010, Jonas M. Börner wrote: Hi all, I am trying to use the convolutional encoder and Viterbi provided by the gr-trellis class within another environment. I have my own mapper and de-mapper blocks which I want to use. So I tried to use the feed the viterbi_combined with this arguments: va_combined = trellis.viterbi_combined_fb(fo,nsymbols,0,-1,1,[-1,1],trellis.TRELLIS_EUCLIDEAN) My de-mapper outputs soft bits between -1 and +1. Here is an example output of my test script: data: [0, 1, 1, 0, 0] encoded:(0, 3, 2, 2, 0) unpacked: (0, 0, 1, 1, 1, 0, 1, 0, 0, 0) modulated: ((1+0j), (1+0j), (-1+0j), (-1+0j), (-1+0j), (1+0j), (-1+0j), (1+0j), (1+0j), (1+0j)) demodulated:(-1.0, -1.0, 1.0, 1.0, 1.0, -1.0, 1.0, -1.0, -1.0, -1.0) decoded:(0, 0, 1, 0, 0, 1, 0, 1, 0, 1) Another thing I don't understand is why the decoder outputs 10 values instead of 5. I would be glad if someone told me what I am doing wrong. Regards, Jonas If I remember correctly, when you start pushing symbols through the trellis, it has some zero values before the input and some zero values after your last symbol pushed into the trellis. I think this is typically the length of your trellis. So at some point you will have to truncate the trellis output. Any one else care to comment? --Colby Boyer I have not used the GNU Radio trellis before. In the past, I have only used the the matlab trellis and I remember I had to deal with truncating. --Colby___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
