Re: [Discuss-gnuradio] USRP Dynamic Range and 8 Bit Problem
Hi Firas, >>I think we could quickly double the processing gain (and gain 6 dB >>S/N >>and dynamic range at higher decimation rates) by either shifting >>by 4 >>bits before the CORDIC stage or eliminating the divide by 2 at >>the end >>of the CORDIC stage. Can you modify the FPGA quickly and send me the RBF file?. I want to make use from the measuring equipments I have currently to test the modifications before I return it back. It has been on my (long) list of things to do, but so far I have never built an RBF file and don't have the tools to do so. But I can point to the places in the Verilog code that I would change, if that would help. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Dynamic Range and 8 Bit Problem
Hi Don, >>Don Ward <[EMAIL PROTECTED]> wrote: >>I don't have the tools to do so. No tools are required. All what you have to do is to download the free windows Altera FPGA design software (Quartus II Web edition) from : http://www.altera.com/products/software/products/quartus2web/sof-quarwebmain.html >>But I can point to the places in the Verilog code that I would change >> if that would help. Alternatively (In this case I think it is quicker), tell me the places in verilog code to be changed, and I will modify it and recompile the rbf file and test it. Regards, Firas A. Don Ward <[EMAIL PROTECTED]> wrote: Hi Firas, > >>I think we could quickly double the processing gain (and gain 6 dB >>S/N > >>and dynamic range at higher decimation rates) by either shifting >>by 4 > >>bits before the CORDIC stage or eliminating the divide by 2 at >>the end > >>of the CORDIC stage. > > Can you modify the FPGA quickly and send me the RBF file?. I want to make > use from the measuring equipments I have currently to test the > modifications before I return it back. It has been on my (long) list of things to do, but so far I have never built an RBF file and don't have the tools to do so. But I can point to the places in the Verilog code that I would change, if that would help. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Dynamic Range and 8 Bit Problem
I don't have the tools to do so. No tools are required. All what you have to do is to download the free windows Altera FPGA design software (Quartus II Web edition) . . . Yeah, that's the part I haven't done yet . . . Alternatively (In this case I think it is quicker), tell me the places in verilog code to be changed, and I will modify it and recompile the rbf file and test it. The safest (I think) is to change the assignments at the end of cordic.v from assign xo = x12[bitwidth:1]; assign yo = y12[bitwidth:1]; to assign xo = x12[bitwidth-1:0]; assign yo = y12[bitwidth-1:0]; You might (or might not) get slightly better results by changing the scaling in adc_interface.v instead, from adc0[11],adc0,3'b0 to adc0,4'b0 (and similar for adc1, adc2, and adc3), but it would need to be verified that this won't overflow the cordic stage. Change cordic.v or adc_interface.v, but not both. The final tweak would be to change the scaling table in cic_dec_shifter.v from ceil(N*log2(rate)) to ceil( N*log2(rate) + log2(1.6467/2) ) to use some of the range lost in the CORDIC stage with some decimations. Regards, -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Flex2400 and benchmark_rx.py - receiving only fraction of packets
Hi all, I am working with Flex2400 boards and the USRP. I have a question about the digital module (GMSK data transfer). I observe this: When I send 660 packets , I receive less than 400 of them and less than 200 are correct. I setup two PCs with ubuntu and with an USRP each. The antennas were connected to the TX/RX ports on each USRP and separated around 3.2m. Basic tests such as oscope and fft work fine, with one side sending. Then with benchmark, on one end I use: ./benchmark_tx.py -f 2.412G --tx-amplitude=2 -v -r 500k and the other ./benchmark_rx.py -f 2.412G --rx-gain=70 -v -r 500k For different runs, errors happen and in a typical run I get something like ok = False pktno = 662 n_rcvd = 355 n_right = 164 I did the following (which did not help) 1) varied rx gain and tx_amplitude over a range 2) checked the frequency 2.412 (using oscope and iwlist) and also changed to other free frequencies 3) repeated experiment at a different time and day The ratio of the pktno to n_rcvd and n_right remains almost the same for different runs. Further, if I send send traffic the other way, I get lesser number of packets (100) correct. Has anyone seen something like this? Specifically, I am looking at why the RX would receive only a fraction of packets and why only a smaller fraction would pass crc? Thanks for your help, Sri. P.S. I am attaching the output of the rx side. [EMAIL PROTECTED]:~/gnuradio/gnuradio-examples/python/digital$ ./benchmark_rx.py -f 2.412G --rgain=50 -v -r 500k >>> gr_fir_fff: using SSE bits per symbol = 1 M&M clock recovery omega = 2.00 M&M clock recovery gain mu = 0.175000 M&M clock recovery mu = 0.50 M&M clock recovery omega rel. limit = 0.005000 frequency error = 0.00 Receive Path: Using RX d'board B: Flex 2400 Rx MIMO B Rx gain: 50 modulation: gmsk_demod bitrate: 500kb/s samples/symbol:2 decim:64 Rx Frequency:2.412G Warning: Failed to enable realtime scheduling. ok = True pktno =0 n_rcvd =1 n_right =1 ok = True pktno =1 n_rcvd =2 n_right =2 ok = True pktno =2 n_rcvd =3 n_right =3 ok = True pktno =3 n_rcvd =4 n_right =4 ok = True pktno =4 n_rcvd =5 n_right =5 ok = True pktno =5 n_rcvd =6 n_right =6 ok = True pktno =6 n_rcvd =7 n_right =7 ok = True pktno =7 n_rcvd =8 n_right =8 ok = True pktno =8 n_rcvd =9 n_right =9 ok = True pktno =9 n_rcvd = 10 n_right = 10 ok = True pktno = 10 n_rcvd = 11 n_right = 11 ok = True pktno = 11 n_rcvd = 12 n_right = 12 ok = True pktno = 12 n_rcvd = 13 n_right = 13 ok = True pktno = 13 n_rcvd = 14 n_right = 14 ok = True pktno = 14 n_rcvd = 15 n_right = 15 ok = True pktno = 15 n_rcvd = 16 n_right = 16 ok = True pktno = 16 n_rcvd = 17 n_right = 17 ok = True pktno = 17 n_rcvd = 18 n_right = 18 ok = True pktno = 18 n_rcvd = 19 n_right = 19 ok = True pktno = 19 n_rcvd = 20 n_right = 20 ok = True pktno = 20 n_rcvd = 21 n_right = 21 ok = True pktno = 21 n_rcvd = 22 n_right = 22 ok = True pktno = 22 n_rcvd = 23 n_right = 23 ok = True pktno = 23 n_rcvd = 24 n_right = 24 ok = True pktno = 24 n_rcvd = 25 n_right = 25 ok = True pktno = 25 n_rcvd = 26 n_right = 26 ok = True pktno = 26 n_rcvd = 27 n_right = 27 ok = True pktno = 27 n_rcvd = 28 n_right = 28 ok = True pktno = 28 n_rcvd = 29 n_right = 29 ok = True pktno = 29 n_rcvd = 30 n_right = 30 ok = True pktno = 30 n_rcvd = 31 n_right = 31 ok = True pktno = 31 n_rcvd = 32 n_right = 32 ok = True pktno = 32 n_rcvd = 33 n_right = 33 ok = True pktno = 33 n_rcvd = 34 n_right = 34 ok = True pktno = 34 n_rcvd = 35 n_right = 35 ok = True pktno = 35 n_rcvd = 36 n_right = 36 ok = True pktno = 36 n_rcvd = 37 n_right = 37 ok = True pktno = 37 n_rcvd = 38 n_right = 38 ok = True pktno = 38 n_rcvd = 39 n_right = 39 ok = True pktno = 39 n_rcvd = 40 n_right = 40 ok = True pktno = 40 n_rcvd = 41 n_right = 41 ok = True pktno = 41 n_rcvd = 42 n_right = 42 uOok = True pktno = 42 n_rcvd = 43 n_right = 43 ok = True pktno = 43 n_rcvd = 44 n_right = 44 ok = True pktno = 44 n_rcvd = 45 n_right = 45 ok = True pktno = 45 n_rcvd = 46 n_right = 46 ok = True pktno = 46 n_rcvd = 47 n_right = 47 uOok = True pktno = 47 n_rcvd = 48 n_right = 48 ok = True pktno = 48 n_rcvd = 49 n_right = 49 ok = True pktno = 49 n_rcvd = 50 n_right = 50 ok = True pktno = 50 n_rcvd = 51 n_right = 51 uOok = True pktno = 51 n_rcvd = 52 n_right = 52 ok = False pktno = 52 n_rcvd = 53 n_right = 52 ok = False pktno = 54 n_rcvd = 54
Re: [Discuss-gnuradio] Flex2400 and benchmark_rx.py - receiving only fraction of packets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 sri ram wrote: > P.S. I am attaching the output of the rx side. uOok = True pktno = 47 n_rcvd = 48 n_right = 48 ok = True pktno = 48 n_rcvd = 49 n_right = 49 ok = True pktno = 49 n_rcvd = 50 n_right = 50 ok = True pktno = 50 n_rcvd = 51 n_right = 51 uOok = True pktno = 51 n_rcvd = 52 n_right = 52 ok = False pktno = 52 n_rcvd = 53 n_right = 52 ok = False pktno = 54 n_rcvd = 54 n_right = 52 uOok = False pktno = 56 n_rcvd = 55 n_right = 52 ok = False pktno = 58 n_rcvd = 56 n_right = 52 - -- The USRP Overruns (the 'uO's indicated above) mean that your computer is not fast enough to process this data. Is the processor too slow? Are you running other applications in the background? - -Dan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHcA9ry9GYuuMoUJ4RAgAHAKDQ+eAYlPfur+vSr+OGdxrCZHbNSwCfWC/L G7g4Eh02xuO44VpTl/KtFr4= =CSgi -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flex2400 and benchmark_rx.py - receiving only fraction of packets
Hello Dan, I see that the u0 occurs once every 3 entries which could explain the ratio between the packets that are received and sent. I am using a Pentium4 1.8GHz CPU. 'top' tells me that the processor is 98% free and memory is also 95% free. Do you still think that this computer is slow or is there any other problem that could have happened (such as the USB)? I use a USB PCI card and the usrp_benchmark_usb gives 16MBps without u0s. Thanks for your quick response, Sriram. On Dec 24, 2007 2:58 PM, Dan Halperin <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > sri ram wrote: > > P.S. I am attaching the output of the rx side. > > uOok = True pktno = 47 n_rcvd = 48 n_right = 48 > ok = True pktno = 48 n_rcvd = 49 n_right = 49 > ok = True pktno = 49 n_rcvd = 50 n_right = 50 > ok = True pktno = 50 n_rcvd = 51 n_right = 51 > uOok = True pktno = 51 n_rcvd = 52 n_right = 52 > ok = False pktno = 52 n_rcvd = 53 n_right = 52 > ok = False pktno = 54 n_rcvd = 54 n_right = 52 > uOok = False pktno = 56 n_rcvd = 55 n_right = 52 > ok = False pktno = 58 n_rcvd = 56 n_right = 52 > > - -- > > The USRP Overruns (the 'uO's indicated above) mean that your computer is > not fast enough to process this data. Is the processor too slow? Are you > running other applications in the background? > > - -Dan > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFHcA9ry9GYuuMoUJ4RAgAHAKDQ+eAYlPfur+vSr+OGdxrCZHbNSwCfWC/L > G7g4Eh02xuO44VpTl/KtFr4= > =CSgi > -END PGP SIGNATURE- > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flex2400 and benchmark_rx.py - receiving only fraction of packets
Hello Dan, Using a higher decimation rate (128) , that problem does not arise. Thanks, Sriram On Dec 24, 2007 3:16 PM, sri ram <[EMAIL PROTECTED]> wrote: > Hello Dan, > I see that the u0 occurs once every 3 entries which could > explain the ratio between the packets that are received and sent. > > I am using a Pentium4 1.8GHz CPU. 'top' tells me that the processor is 98% > free and memory is also 95% free. > Do you still think that this computer is slow or is there any other > problem that could have happened (such as the USB)? > I use a USB PCI card and the usrp_benchmark_usb gives 16MBps without u0s. > > Thanks for your quick response, > Sriram. > > > On Dec 24, 2007 2:58 PM, Dan Halperin <[EMAIL PROTECTED]> wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > sri ram wrote: > > > P.S. I am attaching the output of the rx side. > > > > uOok = True pktno = 47 n_rcvd = 48 n_right = 48 > > ok = True pktno = 48 n_rcvd = 49 n_right = 49 > > ok = True pktno = 49 n_rcvd = 50 n_right = 50 > > ok = True pktno = 50 n_rcvd = 51 n_right = 51 > > uOok = True pktno = 51 n_rcvd = 52 n_right = 52 > > ok = False pktno = 52 n_rcvd = 53 n_right = 52 > > ok = False pktno = 54 n_rcvd = 54 n_right = 52 > > uOok = False pktno = 56 n_rcvd = 55 n_right = 52 > > ok = False pktno = 58 n_rcvd = 56 n_right = 52 > > > > - -- > > > > The USRP Overruns (the 'uO's indicated above) mean that your computer is > > > > not fast enough to process this data. Is the processor too slow? Are you > > running other applications in the background? > > > > - -Dan > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.4.6 (GNU/Linux) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > > > iD8DBQFHcA9ry9GYuuMoUJ4RAgAHAKDQ+eAYlPfur+vSr+OGdxrCZHbNSwCfWC/L > > G7g4Eh02xuO44VpTl/KtFr4= > > =CSgi > > -END PGP SIGNATURE- > > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OLPC - next generation with SDR?
As preface, I'm not a radio engineer. I'm a software guy with pretentions to understanding digital hardware. I have a few signal processing books on a dusty shelf. You lose me as soon as you start talking "Q signals". The Odyssey board operates at 10MHz IF; so wouldn't it need an external tuner? > I am in agreement with Frank that we can currently do it for a few tens > of dollars ~$50 in small quantities and that include parts and boards. > We can even put together a prototype which will allow HF shortwave > reception from low bands through about 21 Mhz covering these bands: > [15m thru 120m] What kind of antenna would this require? Something external to the laptop? Or something that could be built into the plastic case? > The dsPIC33 has more than enough horsepower to provide good > (synchronous) detected AM and even some modest AGC. We won't need a processor; the laptop will come with a processor much faster than 40 MIPS. (The current XO CPU is a Geode LX 433 MHz x86, with MMX, 3DNow, and some SSE instructions.) > We need a DDS and a QSD (we do not need the QSE for the receive only > version) if we are going to tune the HF shortwave broadcast bands and > get reasonable performance at low cost. I think that single chips are available that do broadcast-band AM and FM decoding for cheap; has nobody done this for the television and shortwave bands? Or is the problem that nobody's done this digitally? If we can provide something that gives real benefit for the target kids, we shouldn't be dogmatic about analog versus digital. Alternatively, if OLPC provided a million-unit order for a digital tuner chip that would target all these bands, others could then buy the cheap chip for a variety of projects. > This would provide a clear example of how it could be done. It does not > meet the price point, but it shows the capabilities and then we can > negotiate. I'm glad you-all are pointing out low volume prototypes. I hope we'll get someone interested who has designed high volume digital radio electronics. High volume ~= million-unit. (Do any people like this exist? Perhaps Matt's bluetooth design has shipped in that quantity; WiFi does too.) There's already an entire high speed digital radio transceiver in the existing XO: it's the Marvell "Libertas" WiFi 88W8388 controller chip and 88W8015 radio chip. It's reprogrammable, though the ARM code that runs in it isn't open source yet (the high level code can be open sourced, but it runs on a proprietary RTOS). I think the best strategy for a $50 laptop's radio would be to have either an internal antenna or a single connector; a small number of cheap analog components; perhaps *one* analog/digital chip (multi channel DAC/ADC "radio chip"); and stuff *everything* else into a corner of the digital system-on-chip that implements the rest of the laptop. It's hard to prototype such a thing, though perhaps using an FPGA that come with a fast embedded MIPS or ARM CPU would be the closest. The current XO uses two custom chips (the DCON display controller, and the CAFE camera/flash/SD controller), some very custom "mesh" firmware for the ARM core inside the WiFi chip, and some very custom firmware for the EC embedded controller battery charger chip. A $50 laptop version would probably mash all these chips together with the CPU, GPU, and its "southbridge" support chip, leaving only one system-on-chip, plus flash, DRAM, a few external analog chips, and a pile of analog electronics for power supply and such. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OLPC - next generation with SDR?
On Mon, Dec 24, 2007 at 02:11:34PM -0800, John Gilmore wrote: > I'm glad you-all are pointing out low volume prototypes. I hope we'll > get someone interested who has designed high volume digital radio > electronics. High volume ~= million-unit. (Do any people like this > exist? Perhaps Matt's bluetooth design has shipped in that quantity; > WiFi does too.) There's already an entire high speed digital radio > transceiver in the existing XO: it's the Marvell "Libertas" WiFi > 88W8388 controller chip and 88W8015 radio chip. It's reprogrammable, > though the ARM code that runs in it isn't open source yet (the high > level code can be open sourced, but it runs on a proprietary RTOS). You may be disappointed what you can accomplish with the ARM microcontroller. It is not responsible for mod/demod. Those functions are in silicon. If Marvell would publish the 88W8388 and 88W8015 documentation, it would jumpstart some open-source development. Source code is a poor replacement for proper chipset documentation. Dave -- David Young OJC Technologies [EMAIL PROTECTED] Urbana, IL * (217) 278-3933 ext 24 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OS X Leopard usrper error - omnithread?
Just built GNU Radio on Mac OS X Leopard, and the "Hello World" Dial Tone example worked fine. Tried running 'usrper' to see if it built OK and got the following error: dyld: lazy symbol binding failed: Symbol not found: __ZN11omni_thread6init_tC1Ev Referenced from: /Users/andrew/gr2/lib/libusrp.0.dylib Expected in: flat namespace dyld: Symbol not found: __ZN11omni_thread6init_tC1Ev Referenced from: /Users/andrew/gr2/lib/libusrp.0.dylib Expected in: flat namespace There is no usrp attached. Eagerly awaiting delivery and thought I'd try and get as much as I could ready in advance. Perhaps with no device attached this error is normal, but suspected something in my build/environment may be wrong. LDFLAGS is set and lib/ contains: rhys:lib andrew$ ls -l libgr* -rwxr-xr-x 1 andrew staff 32544 24 Dec 23:44 libgromnithread.0.0.0.dylib lrwxr-xr-x 1 andrew staff 27 24 Dec 23:44 libgromnithread.0.dylib -> libgromnithread.0.0.0.dylib lrwxr-xr-x 1 andrew staff 27 24 Dec 23:44 libgromnithread.dylib -> libgromnithread.0.0.0.dylib -rwxr-xr-x 1 andrew staff913 24 Dec 23:44 libgromnithread.la Tried with build from SVN and 3.1.1 tarball. Have I missed something? Or should I just wait for the usrp to arrive... Regards, Andrew --- Andrew Back MIEEE MBCS CITP Open Systems Engineer Osmosoft - open source applications from BT E: [EMAIL PROTECTED] T: 07795 987822 http://www.osmosoft.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OS X Leopard usrper error - omnithread?
Andrew - You'll need to work with the SVN trunk as of r7252 (yesterday). I checked in changes for OSX (any version) to include the omnithread library in the compilation of the USRP's library and applications. Updating to the latest SVN will take care of the "Symbol not found" issue; I don't know about the USRP or not issue. - MLD On Dec 24, 2007, at 7:07 PM, Andrew Back wrote: Just built GNU Radio on Mac OS X Leopard, and the "Hello World" Dial Tone example worked fine. Tried running 'usrper' to see if it built OK and got the following error: dyld: lazy symbol binding failed: Symbol not found: __ZN11omni_thread6init_tC1Ev Referenced from: /Users/andrew/gr2/lib/libusrp.0.dylib Expected in: flat namespace ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OS X Leopard usrper error - omnithread?
On 25/12/07 00:30, "Michael Dickens" <[EMAIL PROTECTED]> wrote: > Andrew - You'll need to work with the SVN trunk as of r7252 > (yesterday). I checked in changes for OSX (any version) to include > the omnithread library in the compilation of the USRP's library and > applications. Updating to the latest SVN will take care of the > "Symbol not found" issue; I don't know about the USRP or not issue. - That appears to have done the trick, many thanks Michael! Regards, Andrew ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OLPC - next generation with SDR?
On Dec 24, 2007 5:11 PM, John Gilmore <[EMAIL PROTECTED]> wrote: The Odyssey board operates at 10MHz IF; so wouldn't it need an external > tuner? Yes, but many different tuners (band sets) can be serviced by the same IF processor. > What kind of antenna would this require? Something external to the > laptop? Or something that could be built into the plastic case? Depending on the band it could be either or both. A multiloop MW/HF could be embedded in the plastic case. A gender-bent SMA could accommodate a wide variety of V/U/SHF antennas. > > We won't need a processor; the laptop will come with a processor much > faster than 40 MIPS. (The current XO CPU is a Geode LX 433 MHz x86, > with MMX, 3DNow, and some SSE instructions.) We can argue that a "radio coprocessor" would greatly enhance the range of possibilities -- DRM (Digital Radio Mondiale) for example, and see below. > > We need a DDS and a QSD (we do not need the QSE for the receive only > > version) if we are going to tune the HF shortwave broadcast bands and > > get reasonable performance at low cost. > > I think that single chips are available that do broadcast-band AM and > FM decoding for cheap; has nobody done this for the television and > shortwave bands? Or is the problem that nobody's done this digitally? Two problems. One is that the off-the-shelf chips use proprietary IP. The other is that the off-the-shelf chips are locked up and it's next to impossible to do anything interesting with them that you can't already do with a cheap external radio. I'm not aware of commercial devices that could be used to capture and detect *all* of the signals within a 50 kHz bandwidth, which could probably be done with ease with the assistance of a radio coprocessor. This is an essential step towards "cognitive" functions -- make the radio functions mutable and dynamic. > If we can provide something that gives real benefit for the target > kids, we shouldn't be dogmatic about analog versus digital. > Alternatively, if OLPC provided a million-unit order for a digital > tuner chip that would target all these bands, others could then buy the > cheap chip for a variety of projects. > > > This would provide a clear example of how it could be done. It does not > > meet the price point, but it shows the capabilities and then we can > > negotiate. > > I'm glad you-all are pointing out low volume prototypes... I'd think in part we'd be providing not just sealed up applications but also programmable devices and an API, capable of being used in innovative ways in software *without* requiring the chronic intervention of large-scale chip producers. Part of the SDR mission, isn't it? Regards Frank AB2KT ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Dynamic Range and 8 Bit Problem
Dear Don W., 1) Modifying the FPGA file (cordic.v) as you suggested was working fine. The USRP dynamic range was greatly enhanced as follows (the test was done for decimation rate of 8, using BasicRx board, and sine wave frequency =250KHz): a) For 9 dBm i/p signal, max count was 26198 (previously was 13096). b) For 10 dBm (Saturating signal), The max count was 26830 ( previously was 13570). 2) I did not tested modifying cic_dec_shifter.v scaling table yet ,but I will do it later. 3) After doing more tests (checking other decimation rates), I think you (or I) must send this modification as a patch to patch-gnuradio. Thank you. Firas A. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
