Re: [Discuss-gnuradio] not responding B100
Hi Tapiwa, There should be object code for fixing the B100 USB interface in the UHD tree under /host/build/utils. cmake compiled it for you when you built the whole UHD. The bin file to use is fx2_init_eeprom. Use the --help option to get usage info. You also need the suitable b100_boot.bin and b100_eeprom.bin to be flashed into the B100. I'm actually having those but I'm not sure whether or not they're the good version for your board revison. I'm actually haning no clue on the versioning of such files. Seeking advice from other list members on this. Best Vincenzo Il giorno 13/mag/2014 12:10, "Tapiwa Chiwewe" ha scritto: > Hi Vince, > > I hope I find you well. I found your message online about a non-responsive > B100. I seem to be having a problem similar to yours, may I ask if you ever > found a solution to the 'bricked' B100? > > Kind regards > Tapiwa > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] not responding B100
Hi List, My B100 suddenly stopped responding to UHD init. It appears that the USB interface actually lost its ability to identify as a device. Here below, you can find the output of the fedora "messages" log for the Broken B100 as well as for a working one. Could this be solved by re-programming the USB interface somehow? my best regards vince _ Bricked B100 Sep 9 17:43:25 vince kernel: [293521.821638] usb 1-1.2: USB disconnect, device number 23 Sep 9 17:43:28 vince kernel: [293524.558326] usb 1-1.2: new high-speed USB device number 25 using ehci_hcd Sep 9 17:43:28 vince kernel: [293524.643549] usb 1-1.2: New USB device found, idVendor=0a00, idProduct=0002 Sep 9 17:43:28 vince kernel: [293524.643554] usb 1-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Sep 9 17:43:28 vince mtp-probe: checking bus 1, device 25: "/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.2" Sep 9 17:43:28 vince mtp-probe: bus: 1, device: 25 was not an MTP device Good B100 Sep 9 17:43:28 vince mtp-probe: bus: 1, device: 25 was not an MTP device Sep 9 17:43:58 vince kernel: [293555.356431] usb 1-1.2: USB disconnect, device number 25 Sep 9 17:44:17 vince kernel: [293573.964334] usb 1-1.2: new high-speed USB device number 26 using ehci_hcd Sep 9 17:44:17 vince kernel: [293574.050317] usb 1-1.2: New USB device found, idVendor=2500, idProduct=0002 Sep 9 17:44:17 vince kernel: [293574.050322] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=6 Sep 9 17:44:17 vince kernel: [293574.050326] usb 1-1.2: Product: USRP B1004 Sep 9 17:44:17 vince kernel: [293574.050328] usb 1-1.2: Manufacturer: Ettus Research LLC Sep 9 17:44:17 vince kernel: [293574.050330] usb 1-1.2: SerialNumber: E8R10ZFB1 Sep 9 17:44:17 vince mtp-probe: checking bus 1, device 26: "/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.2" Sep 9 17:44:17 vince mtp-probe: bus: 1, device: 26 was not an MTP device Sep 9 17:44:49 vince kernel: [293606.298898] usb 1-1.2: USB disconnect, device number 26 -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] See a demo of our new USRP as DEFCON
Hi Matt, This is very good news. The specs you're anticipating are of great interest to me. Just a further question: Is the B200 conceived in order to support 24/7 continuous operation (e.g. the sort of use case you would expect in a permanent spectrum monitoring application)? If so, have you already or will you have some characterization figures in this regard (an MTBF or the like)? Cheers ...and good luck with your great work Vince Il giorno 02/ago/2013 02:10, "Matt Ettus" ha scritto: > > For those lucky enough to be going to DEFCON, Balint Seeber (our > applications engineer) will be presenting "All Your RFz Are Belong to Me -- > Hacking the Wireless World with SDR", in Track 4 from 10 AM to 11:45. He > will be running all of his demos on the USRP B200, which we are going to > release very soon. > > The low-cost B200 has frequency coverage of 50 MHz to 6 GHz, with 56 MHz > of instantaneous bandwidth (at 61.44 MS/s) over a USB 3 interface. The > B210 adds 2x2 MIMO capability and a bigger FPGA. The device is bus-powered > so there is no need for an external power supply. It *already* runs GNU > Radio, OpenBTS, LTE, and anything else that runs on our other USRPs. > > Balint's talks are always very exciting, so be sure to check it out if you > are at the conference. He is going to demonstrate RFID hacking (on > FastTrak toll passes), LTE, OpenBTS, and numerous other applications he has > developed. > > For those not lucky enough to be there, here is a brief taste of it: > > http://t.co/GyCijVunPx > > Matt > > > ___ > 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] OFDM behaviour of recent UHDs
hi Josh, thanks for the very prompt answer. Will run the tests you suggest tomorrow morning (CET) and let you know. As to the power, the receiver measures the very same received power value in both cases. You can see this from the (first from top) bar indicator on the instrument in the two pics. regards vince 2013/4/15 Josh Blum > > > On 04/15/2013 03:39 PM, Vincenzo Pellegrini wrote: > > Hi everybody, > > > > I have been experiencing some difficulties in obtaining > > the same "signal clarity" performance that I used to have with > > > > uhd_003.004.000-f500b92 > > > > when I tried to transmit the same samples of the same signal > > (also same usrp B100, same XCVR2450 front-end, same frequency =5.8GHz, > same > > receiving device, same tx/rx antenna positions) > > with both: > > > > uhd_003.005.001 > > and > > uhd_003.005.002 > > > > at the following links you can find images of a DVB-T modulation analyzer > > exposed to both transmissions. > > > > www.pellegrini-radio.it/uhd_003.004.000-f500b92.jpg > > www.pellegrini-radio.it/uhd_003.005.002.jpg > > > > If you look at the MER value, a much poorer constellation quality is > > evident when operating with the newer UHD and its matched images. > > (no performance difference was noticed in this respect between > > uhd_003.005.001 and uhd_003.005.002). > > > > Has this been experienced before? > > As somethin changed in between that I should be aware of? > > > > If 3.4.0 worked, I would definitely give 3.4.5 a try to see if any of > the patches or fixes could have inadvertently caused the issue. That > will at least narrow down which versions are causing the difference. > > There was a fix to DSP scaling to prevent clipping. Its possible that > the power level is simply lower? What signal amplitude are you using, > and does doubling it solve the issue? > > http://code.ettus.com/redmine/ettus/projects/uhd/wiki/ChangeLog#003004005 > > -josh > > > my best regards to everybody > > > > vince > > > > > > > > ___ > > 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 > -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OFDM behaviour of recent UHDs
Hi everybody, I have been experiencing some difficulties in obtaining the same "signal clarity" performance that I used to have with uhd_003.004.000-f500b92 when I tried to transmit the same samples of the same signal (also same usrp B100, same XCVR2450 front-end, same frequency =5.8GHz, same receiving device, same tx/rx antenna positions) with both: uhd_003.005.001 and uhd_003.005.002 at the following links you can find images of a DVB-T modulation analyzer exposed to both transmissions. www.pellegrini-radio.it/uhd_003.004.000-f500b92.jpg www.pellegrini-radio.it/uhd_003.005.002.jpg If you look at the MER value, a much poorer constellation quality is evident when operating with the newer UHD and its matched images. (no performance difference was noticed in this respect between uhd_003.005.001 and uhd_003.005.002). Has this been experienced before? As somethin changed in between that I should be aware of? my best regards to everybody vince -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP LO Relocation Latency
Hi Josh, thanks for the answer, so you confirm times in the range of the hundreds of micro secs? are WBX and SBX the best performing daughterboards in this repsect? where can I find the ADI docs you quote in your email? thank you and best regards. vince 2012/9/26 Josh Blum > > > On 09/26/2012 01:00 PM, Vincenzo Pellegrini wrote: > > Dear gr / USRP fellows, > > > > I'm currently experimenting with USRP B100 Local Oscillator relocation > time. > > I've done some experiments on the RX path by tuning towards and away from > > an OFDM beacon signal. > > > > I have flushed into the received signal some recognizable "relocation > > marks" which allowed me to analyze the > > received signal integrity in the temporal vicinity of the relocation > > instant. > > > > It looks like the LO responds to the steering command in some > milliseconds > > to about two tens of millisecs, > > still "artifacts" such as unsuppressed, dominant carrier or unstable gain > > remain there for some hundreds of millisecs. > > > > I saw that the wiki states "perhaps a second" as the LO settling time. > > But can anybody confirm the above behaviour analysis ? > > It depends on the daughterboard. SBX and WBX have a worst case settling > time of about 300us according to the ADI docs. > > You should also be able to schedule tuning through time commands so that > the window of "interruption" is explicitly between time X and X + 300us. > > Here is some psudo code involving using timed commands to tune: > > http://files.ettus.com/uhd_docs/manual/html/sync.html#align-los-in-the-front-end-sbx-wbx-n-series > > > -josh > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP LO Relocation Latency
Dear gr / USRP fellows, I'm currently experimenting with USRP B100 Local Oscillator relocation time. I've done some experiments on the RX path by tuning towards and away from an OFDM beacon signal. I have flushed into the received signal some recognizable "relocation marks" which allowed me to analyze the received signal integrity in the temporal vicinity of the relocation instant. It looks like the LO responds to the steering command in some milliseconds to about two tens of millisecs, still "artifacts" such as unsuppressed, dominant carrier or unstable gain remain there for some hundreds of millisecs. I saw that the wiki states "perhaps a second" as the LO settling time. But can anybody confirm the above behaviour analysis ? best regards vince -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP B100 10 MHz specs
Hi everybody, can anybody indicate if ref signal specs for the USRP B100 are to be considered the same as those for N210 as specified here? http://files.ettus.com/uhd_docs/manual/html/usrp2.html#ref-clock-10mhz ...or do look more like those for USRP2 indicated at the very same link. thank you and regards vince -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NEC uPD720200 and USRP B100
some additional info. this is weird: although everything is fine while using 2.0 controllers, when I use the 3.0 expansion card and the b100 gets cold-started (i mean it is not yet loaded with firmware) i get this: dc7900 utils]# ./uhd_find_devices linux; GNU C++ version 4.6.3 20120306 (Red Hat 4.6.3-2); Boost_104700; UHD_003.004.000-1-gea19de0b -- Loading firmware image: /home/soft-rf/Desktop/UHD-Mirror/UHD-images-003.004.000-f500b92/share/uhd/images/usrp_b100_fw.ihx... done No UHD Devices Found if it already has the firmware loaded, I just get: @dc7900 utils]# ./uhd_find_devices linux; GNU C++ version 4.6.3 20120306 (Red Hat 4.6.3-2); Boost_104700; UHD_003.004.000-1-gea19de0b No UHD Devices Found this also happens on a Fedora16 x86_64 machine, and standard USB-memories work well when connected to the expansion board with the NEC 3.0 controller. any clues? regards vince 2012/6/11 Ben Hilburn : > Vincenzo - > > I have the exact same USB 3.0 controller: > 0d:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller > (rev 04) > > ... on this Thinkpad 420s, and I have no issues using the B100. > > Like Nick said, can you provide the output of: > > $ sudo lspci -v > $ uname -a > > Also, without making any changes, if you plug the B100 into a USB2.0 port, > it works fine? > > Cheers, > Ben > > On Mon, Jun 11, 2012 at 10:39 AM, Nick Foster wrote: >> >> On Mon, Jun 11, 2012 at 10:28 AM, Vincenzo Pellegrini >> wrote: >>> >>> Hi Nick and everybody, >>> >>> today I tried to access my B100 via the NEC Corporation uPD720200 >>> usb 3.0 controller that you quoted in this message: >>> >>> http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg35877.html >>> >>> installed on a PCIe USB 3.0 expansion card. >>> >>> UHD could not find devices (./uhd_find_devices) >>> >>> whereas it actually can find my B100 both if it is connected to the USB >>> 2.0 >>> controller on-board the PC motherboard and if it's connected to a PCI >>> USB 2.0 expansion card. >> >> >> Mine's onboard, although it really shouldn't make a difference. Can you >> paste the output of lsusb and lspci -v? >> >> --n >> >>> >>> >>> do you have any search hints for this, is your uPD720200 on-board the >>> motherboard or on a separate device? >>> >>> thanks and regards >>> >>> vincenzo >>> >>> >>> -- >>> Vincenzo Pellegrini >>> http://www.youtube.com/user/wwvince1 >> >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NEC uPD720200 and USRP B100
0, IRQ 17 Memory at fa08 (32-bit, non-prefetchable) [size=16K] Capabilities: [60] Power Management version 3 Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [78] Express Endpoint, MSI 00 Kernel driver in use: snd_hda_intel Kernel modules: snd-hda-intel 03:00.0 USB Controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03) (prog-if 30) Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at fb00 (64-bit, non-prefetchable) [size=8K] Capabilities: [50] Power Management version 3 Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+ Capabilities: [90] MSI-X: Enable+ Count=8 Masked- Capabilities: [a0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Device Serial Number ff-ff-ff-ff-ff-ff-ff-ff Capabilities: [150] #18 Kernel driver in use: xhci_hcd # lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 003: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse Bus 001 Device 004: ID 03f0:0324 Hewlett-Packard SK-2885 keyboard Bus 003 Device 002: ID 2500:0002 uname -a Linux vince.vincehost 2.6.43.5-2.fc15.i686.PAE #1 SMP Tue May 8 11:46:31 UTC 2012 i686 i686 i386 GNU/Linux 2012/6/11 Ben Hilburn : > Vincenzo - > > I have the exact same USB 3.0 controller: > 0d:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller > (rev 04) > > ... on this Thinkpad 420s, and I have no issues using the B100. > > Like Nick said, can you provide the output of: > > $ sudo lspci -v > $ uname -a > > Also, without making any changes, if you plug the B100 into a USB2.0 port, > it works fine? > > Cheers, > Ben > > On Mon, Jun 11, 2012 at 10:39 AM, Nick Foster wrote: >> >> On Mon, Jun 11, 2012 at 10:28 AM, Vincenzo Pellegrini >> wrote: >>> >>> Hi Nick and everybody, >>> >>> today I tried to access my B100 via the NEC Corporation uPD720200 >>> usb 3.0 controller that you quoted in this message: >>> >>> http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg35877.html >>> >>> installed on a PCIe USB 3.0 expansion card. >>> >>> UHD could not find devices (./uhd_find_devices) >>> >>> whereas it actually can find my B100 both if it is connected to the USB >>> 2.0 >>> controller on-board the PC motherboard and if it's connected to a PCI >>> USB 2.0 expansion card. >> >> >> Mine's onboard, although it really shouldn't make a difference. Can you >> paste the output of lsusb and lspci -v? >> >> --n >> >>> >>> >>> do you have any search hints for this, is your uPD720200 on-board the >>> motherboard or on a separate device? >>> >>> thanks and regards >>> >>> vincenzo >>> >>> >>> -- >>> Vincenzo Pellegrini >>> http://www.youtube.com/user/wwvince1 >> >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] NEC uPD720200 and USRP B100
Hi Nick and everybody, today I tried to access my B100 via the NEC Corporation uPD720200 usb 3.0 controller that you quoted in this message: http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg35877.html installed on a PCIe USB 3.0 expansion card. UHD could not find devices (./uhd_find_devices) whereas it actually can find my B100 both if it is connected to the USB 2.0 controller on-board the PC motherboard and if it's connected to a PCI USB 2.0 expansion card. do you have any search hints for this, is your uPD720200 on-board the motherboard or on a separate device? thanks and regards vincenzo -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] REF Signal specs for USRP B100
Hi everybody, can anybody indicate if ref signal specs for the USRP B100 are to be considered the same as those for N210 as specified here? http://files.ettus.com/uhd_docs/manual/html/usrp2.html#ref-clock-10mhz thank you and regards vince -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] B100 as clock master + B100 as clock slave
Yes, there is a demo video on this from 2010 which you can view at my youtube channel http://www.youtube.com/user/wwvince1 It's called Soft-SFN. regards vince Il giorno 27 marzo 2012 16:44, Rafael Diniz ha scritto: > Hi Vince, > > Changing a little the topic, have you managed to run your SoftDVB code to > work on multiple USRPs in order to create a SFN DVB configuration? > > Best regards, > Rafael Diniz > > > Josh, > > I agree this would be a great feature. > > > > vince > > > > > >> > >> There is a clock sync pin (cgen_sync_b in the fpga top level). > >> Presumably, a shared PPS could trigger the clock sync signal across > >> multiple B100. This would synchronously reset the phase across all N > >> devices. It would require a little FPGA work. > >> > >> -Josh > >> > > > -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] B100 as clock master + B100 as clock slave
Thanks Nick, that's perfect. Il giorno 27 marzo 2012 18:05, Nick Foster ha scritto: > On Tue, Mar 27, 2012 at 7:26 AM, Vincenzo Pellegrini wrote: > >> Hi Nick, thanks for the answer. >> >> Everything clear. >> Just a further question. >> Would a 0V-mean, 3.3V peak-to-peak sinusoid be correct as a reference >> signal for the B100? >> > > Use a 5-10dBm reference with no DC component. This corresponds to 1-2V p-p. > > --n > > >> >> regards >> >> vince >> >> >> >> Il giorno 23 marzo 2012 18:30, Nick Foster ha scritto: >> >> On Fri, Mar 23, 2012 at 10:18 AM, Vincenzo Pellegrini >> wrote: >>> >>>> Hi Nick, >>>> I have noticed that "j101" onboard the B100 outputs a 64 MHz reference. >>>> >>>> Could it be possilble to feed that signal somehow into a second USRP >>>> B100 to be used as a reference? >>>> >>> >>> You would have to go through some gymnastics (read: soldering) to get >>> that reference into the second B100, and some code rework to recalculate >>> clock rates based on a 64MHz (or divisor of 64MHz) instead of 10MHz. >>> >>> >>>> >>>> Could it be possible as an alternative to lock two B100 to an external >>>> 10 MHz reference while still working at 8Msps sample rate ? >>>> >>> >>> Yes, this is what the ref in connectors are for. The external reference >>> is independent of the sample rate. The B100s will continue to operate >>> normally, except locked to each other. >>> >>> --n >>> >>> >>> >>>> >>>> my best regards >>>> >>>> vincenzo >>>> >>>> >>>> >>>> >>>> Il giorno 23 marzo 2012 16:54, Nick Foster ha scritto: >>>> >>>> On Fri, Mar 23, 2012 at 3:41 AM, Vincenzo Pellegrini >>>> > wrote: >>>>> >>>>>> Hi everybody, >>>>>> >>>>>> just a very quick question: >>>>>> >>>>>> is it possible to enslave the clock of a B100 to the clock of another >>>>>> B100 via the "REF IN" input or in some other way? >>>>>> More precisely, is there a way to extract the clock signal from a >>>>>> B100 and feed it into another B100 to enslave the latter to the former? >>>>>> >>>>>> It would be great to be able to keep them in frequency and phase >>>>>> synch that way. >>>>>> >>>>> >>>>> Vincenzo, >>>>> >>>>> The ref in input on B100 is intended to accept a 10MHz signal. >>>>> Multiple B100s can be synchronized by using a common reference, but there >>>>> is no facility to lock two B100s to each other without a common external >>>>> reference. >>>>> >>>>> --n >>>>> >>>>> >>>>>> >>>>>> thank you >>>>>> >>>>>> vince >>>>>> >>>>>> -- >>>>>> Vincenzo Pellegrini >>>>>> http://www.youtube.com/user/wwvince1 >>>>>> >>>>>> ___ >>>>>> Discuss-gnuradio mailing list >>>>>> Discuss-gnuradio@gnu.org >>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Vincenzo Pellegrini >>>> http://www.youtube.com/user/wwvince1 >>>> >>> >>> >> >> >> -- >> Vincenzo Pellegrini >> http://www.youtube.com/user/wwvince1 >> > > -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] B100 as clock master + B100 as clock slave
Josh, I agree this would be a great feature. vince > > There is a clock sync pin (cgen_sync_b in the fpga top level). > Presumably, a shared PPS could trigger the clock sync signal across > multiple B100. This would synchronously reset the phase across all N > devices. It would require a little FPGA work. > > -Josh > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] B100 as clock master + B100 as clock slave
Hi Nick, thanks for the answer. Everything clear. Just a further question. Would a 0V-mean, 3.3V peak-to-peak sinusoid be correct as a reference signal for the B100? regards vince Il giorno 23 marzo 2012 18:30, Nick Foster ha scritto: > On Fri, Mar 23, 2012 at 10:18 AM, Vincenzo Pellegrini > wrote: > >> Hi Nick, >> I have noticed that "j101" onboard the B100 outputs a 64 MHz reference. >> >> Could it be possilble to feed that signal somehow into a second USRP B100 >> to be used as a reference? >> > > You would have to go through some gymnastics (read: soldering) to get that > reference into the second B100, and some code rework to recalculate clock > rates based on a 64MHz (or divisor of 64MHz) instead of 10MHz. > > >> >> Could it be possible as an alternative to lock two B100 to an external 10 >> MHz reference while still working at 8Msps sample rate ? >> > > Yes, this is what the ref in connectors are for. The external reference is > independent of the sample rate. The B100s will continue to operate > normally, except locked to each other. > > --n > > > >> >> my best regards >> >> vincenzo >> >> >> >> >> Il giorno 23 marzo 2012 16:54, Nick Foster ha scritto: >> >> On Fri, Mar 23, 2012 at 3:41 AM, Vincenzo Pellegrini >> wrote: >>> >>>> Hi everybody, >>>> >>>> just a very quick question: >>>> >>>> is it possible to enslave the clock of a B100 to the clock of another >>>> B100 via the "REF IN" input or in some other way? >>>> More precisely, is there a way to extract the clock signal from a B100 >>>> and feed it into another B100 to enslave the latter to the former? >>>> >>>> It would be great to be able to keep them in frequency and phase synch >>>> that way. >>>> >>> >>> Vincenzo, >>> >>> The ref in input on B100 is intended to accept a 10MHz signal. Multiple >>> B100s can be synchronized by using a common reference, but there is no >>> facility to lock two B100s to each other without a common external >>> reference. >>> >>> --n >>> >>> >>>> >>>> thank you >>>> >>>> vince >>>> >>>> -- >>>> Vincenzo Pellegrini >>>> http://www.youtube.com/user/wwvince1 >>>> >>>> ___ >>>> Discuss-gnuradio mailing list >>>> Discuss-gnuradio@gnu.org >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >>>> >>> >> >> >> -- >> Vincenzo Pellegrini >> http://www.youtube.com/user/wwvince1 >> > > -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] B100 as clock master + B100 as clock slave
Hi Nick, I have noticed that "j101" onboard the B100 outputs a 64 MHz reference. Could it be possilble to feed that signal somehow into a second USRP B100 to be used as a reference? Could it be possible as an alternative to lock two B100 to an external 10 MHz reference while still working at 8Msps sample rate ? my best regards vincenzo Il giorno 23 marzo 2012 16:54, Nick Foster ha scritto: > On Fri, Mar 23, 2012 at 3:41 AM, Vincenzo Pellegrini wrote: > >> Hi everybody, >> >> just a very quick question: >> >> is it possible to enslave the clock of a B100 to the clock of another >> B100 via the "REF IN" input or in some other way? >> More precisely, is there a way to extract the clock signal from a B100 >> and feed it into another B100 to enslave the latter to the former? >> >> It would be great to be able to keep them in frequency and phase synch >> that way. >> > > Vincenzo, > > The ref in input on B100 is intended to accept a 10MHz signal. Multiple > B100s can be synchronized by using a common reference, but there is no > facility to lock two B100s to each other without a common external > reference. > > --n > > >> >> thank you >> >> vince >> >> -- >> Vincenzo Pellegrini >> http://www.youtube.com/user/wwvince1 >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] B100 as clock master + B100 as clock slave
Hi everybody, just a very quick question: is it possible to enslave the clock of a B100 to the clock of another B100 via the "REF IN" input or in some other way? More precisely, is there a way to extract the clock signal from a B100 and feed it into another B100 to enslave the latter to the former? It would be great to be able to keep them in frequency and phase synch that way. thank you vince -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Performance: Reaching 8Msps TX with USB 2.0 (?)
Hi Nick, thanks for the suggestions. I will test the args. What is the best (maximum?) possible value for the send_frame_size in order to minimize the overhead yielded by UHD? Would it be correct to assume that the over-the-wire overhead yielded by UHD is larger than what the classic libusrp used to impose? If yes, by what scale? The USB peripherals configuration does not differ when I use the classic libusrp version and the UHD. Also, the difference in terms of underflow amount when using the tx_samples_from_file (UHD) and an equivalent classic, libusrp-based utility is huge using the same USB controller, same hard drive, same OS (fedora 16) in both cases. Actually I'm using the very same machine to do the tests. A friend of mine here in Pisa (Mario di Dio, he's also on the list) has obtained the same results on both Ubuntu 11.10 and Fedora 14. He had almost no underruns apart from some at the very beginning when he used his USB 3.0 port and lots of underruns when using the 2.0 USBs of the same laptop. I think I'm seeing something macroscopic, maybe a macroscopic mistake of mine. May I know what version of UHD you are using and your OS? sorry for the many questions, I'm just trying to figure out what I might be missing in order to properly use UHD for my purposes. thanks Il giorno 21 marzo 2012 19:59, Nick Foster ha scritto: > On Wed, Mar 21, 2012 at 11:42 AM, Vincenzo Pellegrini > wrote: > >> HI fellows, >> >> I was wondering if anybody has been trying to reach 8 Complex Msps over >> the USB 2.0 on the Tx path. >> While this has always been OK with old libusrp (and USRP 1) it appears to >> be no longer possible by means of UHD >> neither when trying to do that on USRP1 (a few underruns) nor on B100 >> (lots of overruns). >> >> >> Everything appears instead fine on the Rx path >> >> Is there any workaround to this? >> >> ..or did I miss something? >> >> >> thanks everybody >> >> PS >> USB 3.0 seems to be capable enough for the 8 Msps. >> Is USB3.0 a requirement for 8 Msps on the B100? >> >> > Look for other devices on that USB bus using lsusb. Avoid sharing the bus > with other peripherals (bluetooth, wlan, etc). You can also modify the > transport parameters using > --args=recv_frame_size=x,send_frame_size=x. This will give you the > same control over receive & send frame size that the old USRP1 drivers had. > The default receive/send frame sizes are 16K, which seems to work OK on > most machines. > > For comparison, the USB host controller I'm using is the Intel 6 > Series/C200, and on B100 I can use a TX send rate of 10.67Msps without > underflow, although occasionally underflows occur at the very beginning of > the transmission (likely due to interrupt coalescing on the USB controller). > > I also have a USB 3.0 controller (an NEC Corporation uPD720200) on this > laptop, which fares more poorly, but still easily achieves 8Msps. I don't > have a good explanation as to why some USB controllers do better than > others. USB 3.0 is certainly not required on B100/USRP1, as neither device > uses USB 3.0. > > --n > > >> >> >> B100 >> >> ./benchmark_rate --tx_rate 8e6 >> linux; GNU C++ version 4.6.1 20110908 (Red Hat 4.6.1-9); Boost_104600; >> UHD_003.004.000-325-g7e296167 >> >> >> Creating the usrp device with: ... >> -- USRP-B100 clock control: 10 >> -- r_counter: 2 >> -- a_counter: 0 >> -- b_counter: 20 >> -- prescaler: 8 >> -- vco_divider: 5 >> -- chan_divider: 5 >> -- vco_rate: 1600.00MHz >> -- chan_rate: 320.00MHz >> -- out_rate: 64.00MHz >> -- >> Using Device: Single USRP: >> Device: B-Series Device >> Mboard 0: B100 (B-Hundo) >> RX Channel: 0 >> RX DSP: 0 >> RX Dboard: A >> RX Subdev: WBX RX v3 + Simple GDB >> TX Channel: 0 >> TX DSP: 0 >> TX Dboard: A >> TX Subdev: WBX TX v3 + Simple GDB >> >> Testing transmit rate 8.00 Msps >> >> UU >> Benchmark rate summary: >> Num received samples:0 >> Num dropped samples: 0 >> Num overflows detected: 0 >> Num tr
[Discuss-gnuradio] UHD Performance: Reaching 8Msps TX with USB 2.0 (?)
: 1600.00MHz -- chan_rate: 320.00MHz -- out_rate: 64.00MHz -- -- Loading FPGA image: /usr/share/uhd/images/usrp_b100_fpga.bin... done Using Device: Single USRP: Device: B-Series Device Mboard 0: B100 (B-Hundo) RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: WBX RX v3 + Simple GDB TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: WBX TX v3 + Simple GDB Testing transmit rate 8.00 Msps Benchmark rate summary: Num received samples:0 Num dropped samples: 0 Num overflows detected: 0 Num transmitted samples: 80053688 Num sequence errors: 0 Num underflows detected: 0 Done! -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] phase&frequency synchronization of two USRP1
Hi everybody, just in case somebody has already been doing it. What is the best way (if any) to phase&frequency-synchronize two USRP1? No need to lock them to an external reference. Just need to have the same instantaneous reference clock on both. thanks and regards to all the list vince -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD half bandwidth on USRP1 ?
Hi List, As I'm now fully moving to UHD, I've been trying for a while to do: ./tx_samples_from_file --freq 80950 --rate 8e6 --file /home/vincenzo/Desktop/OFDM_DUMP --type short --bw 8 --subdev A:0 --gain 25 with a USRP1, expecting my OFDM file to be transmitted over the requested 8MHz @ 8 complex Msps bandwidth like it always used to happen when doing the same with the legacy libusrp. unfortunately, although the executable output appears to confirm that the parameters I've requested have been correctly set, on the the spectrum analyser I'm seeing a correct OFDM shape downscaled to a 4 MHz bandwidth. If I reduce the requested rate to 4 Msps, the shape is again correct but downscaled to 2 MHz bandwidth (instead of the 4 MHz that I would be expecting in this case), and so on, getting all the time half the bandwidth I expect. also the USRP 1 carrier peak (using RFX900) is at half the distance from my center frequency than it is when using libusrp instead. has anybody experienced the same ? what am I getting wrong in the tx_samples_from_file example usage or UHD usage? best regards to everybody vincenzo ___BEGIN SCREENDUMP:__ Creating the usrp device with: ... -- Opening a USRP1 device... -- Using FPGA clock rate of 64.00MHz... UACTUAL USRP Master Clock: 6.4e+07 WARNING !!! TEST VERSION ...Using Device: Single USRP: Device: USRP1 Device Mboard 0: USRP1 (Classic) RX Channel: 0 RX DSP: 0 RX Dboard: B RX Subdev: WBX RX v2 + Simple GDB TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: RFX TX Setting TX Rate: 8.00 Msps... Actual TX Rate: 8.00 Msps... Setting TX Freq: 809.50 MHz... Actual TX Freq: 809.50 MHz... Setting TX Gain: 25.00 dB... Actual TX Gain: 0.00 dB... Setting TX Bandwidth: 8.00 MHz... Actual TX Bandwidth: 8.00 MHz... Checking TX: LO: locked ... -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] I hate Unity
Just a couple of lines to cast my ballot in favor of Bob's complaint. I had the same reaction in response to Fedora 15 reception of the Gnome3 thing. That stuff does move too far away from the power-user-desktop concept I've been enjoying for several years as a developer. Also I'm a bit frustrated to have to go after that load of "tweaks" in order to get a freshly installed system usable. my best regards to everybody there vince 2011/10/17 Alexandru Csete > On Mon, Oct 17, 2011 at 7:28 PM, Tom Rondeau > wrote: > > On Mon, Oct 17, 2011 at 10:39 AM, Robert McGwier > > wrote: > >> > >> Install gnome-tweak-tools to get advanced settings for gnome to be able > to > >> get your favorite settings after you install gnome-shell. > >> > >> On Mon, Oct 17, 2011 at 10:04 AM, Robert McGwier > >> wrote: > >>> > >>> > >>> > http://tombuntu.com/index.php/2011/10/03/install-gnome-shell-in-ubuntu-11-10/ > >>> > >>> -- > >>> Bob McGwier > >>> Facebook: N4HYBob > >>> ARS: N4HY > > > > Or do what I did: apt-get install gnome-session-fallback and switch to > Gnome > > Classic Mode at the login screen. Removes Unity. > > I haven't heard anyone say a good thing about Unity. It's an awful > > environment to develop under. The first thing I do in Ubuntu now is stop > > using it. > > I'm now shopping around for another Linux distro if they keep going this > > way. > > Tom > > On Ubuntu 11.04 I have installed Xfce desktop ( http://www.xfce.org/ ) > - it is available via the package manager (or by installing xubuntu > instead of regular ubuntu). It is similar to Gnome 2 and is very > lightweight. > > Alex > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ETSI DVB-T Compliant OFDM Dumps
interleaved (I/Q) short ints (16 bits) as defined by C++ sorry for not having provided this detailed regards vincenzo 2011/4/28 Jeremy Quirke > Hi Vincenzo, > > > > What’s the format of the file. signed I/Q 16-bit little endian? I’m looking > in a hex editor and it does suggest that. > > > > -Jeremy > > > > *From:* discuss-gnuradio-bounces+jqr=jquirke.com...@gnu.org [mailto: > discuss-gnuradio-bounces+jqr=jquirke.com...@gnu.org] *On Behalf Of *Vincenzo > Pellegrini > *Sent:* Wednesday, 27 April 2011 10:26 PM > *To:* discuss-gnuradio > *Subject:* [Discuss-gnuradio] ETSI DVB-T Compliant OFDM Dumps > > > > Hi Fellow GNURadioers, > > > > due to a rather relevant number of requests, as well as while apologizing > for some delay in doing this, > > I'm re-posting to this list a few links to resources regarding GPP-SDR > implemented DVB-T systems. > > > > ETSI DVB-T I/Q BASEBAND DUMP (2048k, 1/4, 16-QAM, 2/3, 11.612Mbps net > bitrate) > > > > www.pellegrini-radio.it/ing/ofdm_40.dump (1 single RAI - RAdiotelevisione > Italiana ch. + stuffing) > > www.pellegrini-radio.it/ing/ofdm_4ch.dump (4 ch, available in a few hours > from now) > > > > > > > > Youtube demo videos: > > > > GPP-SDR implemented DVB-T Modulator over 2.5-Watts Atom N270 > > http://www.youtube.com/watch?v=0mGn7FF9Gc8 > > > > > > GPP-SDR implemented DVB-T DeModulator > > http://www.youtube.com/watch?v=S5nGBDCxhmk > > http://www.youtube.com/watch?v=XxXW4Gya918 > > > > > > GPP-SDR implemented DVB-T SFN > > http://www.youtube.com/watch?v=mQ6YorV4VKE > > > > > > regards to everybody > > > > vince > > > > > > > > > > > > -- > Vincenzo Pellegrini > http://www.youtube.com/user/wwvince1 > -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ETSI DVB-T Compliant OFDM Dumps
Hi Fellow GNURadioers, due to a rather relevant number of requests, as well as while apologizing for some delay in doing this, I'm re-posting to this list a few links to resources regarding GPP-SDR implemented DVB-T systems. ETSI DVB-T I/Q BASEBAND DUMP (2048k, 1/4, 16-QAM, 2/3, 11.612Mbps net bitrate) www.pellegrini-radio.it/ing/ofdm_40.dump (1 single RAI - RAdiotelevisione Italiana ch. + stuffing) www.pellegrini-radio.it/ing/ofdm_4ch.dump (4 ch, available in a few hours from now) Youtube demo videos: GPP-SDR implemented DVB-T Modulator over 2.5-Watts Atom N270 http://www.youtube.com/watch?v=0mGn7FF9Gc8 GPP-SDR implemented DVB-T DeModulator http://www.youtube.com/watch?v=S5nGBDCxhmk http://www.youtube.com/watch?v=XxXW4Gya918 GPP-SDR implemented DVB-T SFN http://www.youtube.com/watch?v=mQ6YorV4VKE regards to everybody vince -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DVB-T software for USRP?
Hi everybody, so far I have not released the Soft-DVB code for a bunch of reasons, which include Soft-DVB code base being one of the main tools of our MA research here at DSPCoLa, Università di Pisa. Still I can easily provide fully compliant DVB-T signal dumps to everybody who is willing to experiment with DVB-T signals over the USRP. I'm also willing to cooperate at various levels with related OFDM / DVB-T projects Regards to all. vincenzo 2011/4/12 Martin Braun > On Mon, Apr 11, 2011 at 09:55:00AM -0700, Andrew Lentvorski wrote: > > On 4/6/11 5:38 AM, Andrew Lentvorski wrote: > > >However, I can't seem to find any downloads for Vincenzo Pellegrini's > > >Soft-DVB code. > > > > I looked some more but I *still* can't find it. > > Hi Andrew, > > Vincenzo's code is, to my best knowledge, neither open source nor > available on the webs. > > 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-43790 > Fax: +49 721 608-46071 > www.cel.kit.edu > > KIT -- University of the State of Baden-Württemberg and > National Laboratory of the Helmholtz Association > > > _______ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DVB-T Modulation over low-end ATOM CPU
Hi William, nice to hear that you appreciate the work. http://www.youtube.com/watch?v=S5nGBDCxhmk Here you can see what happened when we applied MA to our ETSI DVB-T demodulator earlier this year. We demoed this at WSR10, Karlsruhe, Germany. Since then, we increased the amount of MA within the receiver chain, which yielded major computational performance improvements. The dream that we're aiming for is to be able to provide some sort of MA compiler which can automatically implement an SDR including as much as possible of the MA computational benefits, once given a high level C++ description of the radio chain. Regards vince 2010/11/26 William Cox > That's awesome work Vince. > Not being much of a programmer myself, do you plan on releasing any > libraries that would help folks take advantage of this technique? > Also, have you applied MA to demodulation? > Thanks. > -William > > > On Fri, Nov 26, 2010 at 7:32 AM, Vincenzo Pellegrini wrote: > >> Hi fellow GNURadioers, >> >> just in case somebody is interested, this is the main dish of our SDR >> demo, which we will be presenting within GLOBECOM 2010 (Miami, FL) demo >> session on Dec. 8th. Title of the demo is "Showcasing MA potential", as it >> aims to provide a glimpse of computational performance results that one >> might have by applying the programming technique described in >> http://www.pellegrini-radio.it/MA/ to an SDR system. >> >> http://www.youtube.com/watch?v=0mGn7FF9Gc8 >> >> The video proves real-time, live ETSI DVB-T modulation for 4 standard >> resolution channels (11.612 Mbps useful protected bitrate) to be possible >> >> .:. over an Intel ATOM N270 CPU >> .:. which consumes 2.5 Watts of electrical power >> .:. by requiring less than 70 % of its computational power >> >> with nothing but C++ code and MA technique involved. >> We believe there is still margin for application of the MA technique, >> compuational cost can be further reduced. >> >> Of course, not comparable to the power efficiency of an ASIC. Yet. >> >> >> regards to everybody >> >> >> vince >> >> >> >> -- >> Vincenzo Pellegrini >> http://www.youtube.com/user/wwvince1 >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] DVB-T Modulation over low-end ATOM CPU
Hi fellow GNURadioers, just in case somebody is interested, this is the main dish of our SDR demo, which we will be presenting within GLOBECOM 2010 (Miami, FL) demo session on Dec. 8th. Title of the demo is "Showcasing MA potential", as it aims to provide a glimpse of computational performance results that one might have by applying the programming technique described in http://www.pellegrini-radio.it/MA/ to an SDR system. http://www.youtube.com/watch?v=0mGn7FF9Gc8 The video proves real-time, live ETSI DVB-T modulation for 4 standard resolution channels (11.612 Mbps useful protected bitrate) to be possible .:. over an Intel ATOM N270 CPU .:. which consumes 2.5 Watts of electrical power .:. by requiring less than 70 % of its computational power with nothing but C++ code and MA technique involved. We believe there is still margin for application of the MA technique, compuational cost can be further reduced. Of course, not comparable to the power efficiency of an ASIC. Yet. regards to everybody vince -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 10 bit samples
Thank you Thomas (and Marcus) for the replies. I've been using the 8 bit mode un the USRP1 a while ago for a different application. I was looking for a slightly higher precision. I did not know that the usrp2 could not do the 8bit sampling. Thanks for the info. Regards Vince 2010/8/25 Thomas Tsou On Wed, Aug 25, 2010 at 9:58 AM, Vincenzo Pellegrini wrote: > Hi everybody,nd > Just a very simple question: > Is it possible to obtain 10 bit samples out of USRP (either 1 or 2) by using > suitable libusrp primitives / parameters? No. But you can produce 8-bit samples on the USRP1 by appropriately setting the FR_RX_FORMAT register. You can set it through the standard interface. This option is not available on the USRP2. Thomas -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 10 bit samples
Hi everybody, Just a very simple question: Is it possible to obtain 10 bit samples out of USRP (either 1 or 2) by using suitable libusrp primitives / parameters? I mean having 10 bit samples (instead of 16) already over USB / ETHERNET so that one can save bandwidth to be spent in attaining higher sampling rates. I just explored online documentation but was unable to determine this with sufficient confidence. thank you vince ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Full MA paper available
As one must keep his own promises (and I promised indeed a few months ago), here is the link to the full MA paper www.pellegrini-radio.it/MA available for anyone who might be interested in trying to apply these ideas to SDR, especially within the typical GNURadio, GPP-based processing paradigm. Just two very small "release notes" 1. MA Design is not yet a "machine task", i.e. no MA-compiler can be written so far. Still we believe this will be possible. The MA design section called RTAR is indeed already algorithmic, while what we call AS, remains for the moment a human design task. In our opinion, by fixing algorithmic rules for AS, something like an MA-compiler could be rather reasonably written. 2. Still, our current priority is not to make MA "automatic", as this will surely be done in the future, in case MA proves to be an effective technique for SDR implementation. Our aim is instead to prove such effectiveness by showing how big achievable MA acceleration factors may be. I.e. how significantly an SDR might benefit from memory-implementation of some of its critical parts, as long as this can strongly increase performance (energy-efficiency) without causing "losses in system reconfigurability and generality", thus preserving the most valuable peculiarity of an SDR. So far, we've boosted our implementations through MA by something slightly bigger than a factor 10. We obtained this with some months of work, and by applying the concept of "memory space specialization" as described within the attached paper, on an ultra cheap (150 € Intel Q9400) standard CPU. We strongly believe that: A. Obtained acceleration factors can still grow by further applying techniques described within the paper on ordinary commercial GPPs B. Much larger acceleration factors are available if we use computational back-ends being designed ad-hoc for memory based techniques like MA. (i.e. prioritizing memory access wrt pure computation) Our research effort is currently concentrated on proving such two concepts to be right. Upon success, we believe interesting possibilities could open up for SDR as a radio-implementation technology, eventually leading to substantial broadening of its application spectrum. thanks for interest to those interested ;-) , apologies to those that are not. Best Regards to Everybody vince PS. small repost of MA-related video demos / conference presentations, just in case: http://www.youtube.com/watch_videos?more_url=%2Fmy_favorites&video_ids=pwzUKS3OPjo%2CS5nGBDCxhmk%2C_mpPIU1czOs&type=7&index=1&no_autoplay=1 http://www.youtube.com/watch?v=AfvLCh8ADxk http://www.youtube.com/watch?v=XxXW4Gya918 http://www.youtube.com/watch?v=7EuqKYKc6mg -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] MA paper accepted at IEEE Globecom2010
Hi GNURadio and SDR Fellows, for those interested, this short message is just to inform that preliminary, short (IEEE conference style) Memory Acceleration (MA) paper was accepted for presentation at IEEE Globecom 2010. I'm currently checking if I'm allowed to publish on this list the preprint of such paper or if I will publish a differently edited, longer version which is independent from the GC conference. regards to everybody vincenzo -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Soft-SFN (GPS independent, Fully SDR Single Frequency Network) Works :-)
Hi fellow GNURadioers, I'd really like to share with you a demonstration video about something I consider rather cool. http://www.youtube.com/watch?v=mQ6YorV4VKE An ETSI DVB-T Single Frequency Network (SFN) tested within the lab but ready for geographical deployment, implemented by using none of those ultra high-end, GPS-synced SFN hardware modulators but only two ordinary computers and 2 USRP2s. The lab setup reproduces an SFN collision area between two neighboring transmitters (i.e. the worst case a receiver can fall into when operating within an sfn environment). Time and frequency synchronization are delivered to SFN transmitters without relying upon GPS/GALILEO infrastructure but through ordinary (not dedicated) packet switched networks carrying loads of concurrent traffic. I'm not sure this was done before, please let me know in case there is some info I'm missing. thank you and reagards vincenzo -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] New trunk incompatible with old USRPs?
Hi everybody, I have notice an oddity with recent trunks.. since I updated a couple of months ago, my USRP (#541) is not working any more with the current trunk. When I try to send out an 8MHz band, samples get consumed by the USRP slower than they are supposed to. This does not happen if I use old trunks with the #541 or either if I use the current trunk with a recent USRP. Has anybody been experiencing any such thing? Thank you, regards vince ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Controlling multiple USRP 2 on the TX path
Hi everybody, just wanted to know if anything like this was done before by anybody: The idea is to control multiple USRP2 from one single host, over the very same Ethernet link. Like.. the closest possible thing to delivering them a phy-level copy of the very same Ethernet signal and having them transmitting the same samples through whatever front-end daughterboard at whatever frequency. Of course I understand that some bidirectional communication cannot be avoided at least at instantiation time but, provided that we can do that, would it be possible afterwards to deliver multiple USRP2s multiple copies of the same Ethernet frames while having them all transmitting (for sure, I'm thinking about a tx-path-only configuration) the samples contained within ? I don't really know myself if it is possible but, in case it is, that would be opening up unprecedented usage possibilities for the entire USRP2 system. Thanks to all readers of this question Best regards vince ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MA (Memory Acceleration) and SR-DVB in Karlsruhe, @ WSR10
enough flexibility to our new generation of radios. I don't expect approval on this, but my personal opinion is that templates and other similar creatures (probably even classes) are not substantial to SDR. .:. Yes, by programming almost bare-metal as we do, it is easier to make mistakes. But an SDR is not a database and has another peculiarity: It spans very quickly its own state space, as a consequence it is very easy to produce tests that quickly show problems and anomalies. I mean: a bug in a database can appear under some very particular and rare conditions, Soft-DVB and SR-DVB do transit throughout all of their possible states in seconds. If there's something wrong you simply notice it. 4.License I was once told by a GPL enforcer that with Soft-DVB I had two options: release, or put it in a drawer. I did not really know whether he was right or not. But I felt like, after all the work spent there, I wanted to be able to decide myself what to do with the code. What to release, when and how. Maybe just to decide to release everything at once, but actually I felt I had the right to be the one taking such choice. The day after I was developing my own framework. John, thanks for giving me the chance to discuss these issues. Though aware of their scarce popularity, I hope my considerations can be of some utility. I'm interested in further discussion. my best regards to you and everybody vincenzo -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MA (Memory Acceleration) and SR-DVB in Karlsruhe, @ WSR10
Hi Michael, links to WSR10 paper and presentation slides are embedded into the videos from my previous post. Believe me, I would love to post the full MA paper right now. I will do immediately after being allowed to do so by peer reviewing / publication process. I will do all possible efforts to obtain such authorization ASAP. Meanwhile will keep developing MA and provide the most informative possible updates in case anything significant happens. Thanks for being interested. my best regards vincenzo 2010/3/9 Michael Dickens : > Hi Vincenzo - Can you also provide links to your papers, both the WSR10 one > and whatever you can on your MA technique? Enquiring minds will want to > know more about MA ... Thanks! - MLD > -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] MA (Memory Acceleration) and SR-DVB in Karlsruhe, @ WSR10
Hi everybody, here are the links to 3 youtube videos covering SR-DVB Presentation http://www.youtube.com/watch?v=AfvLCh8ADxk SR-DVB Demo + MA (Memory Acceleration) Intro http://www.youtube.com/watch?v=XxXW4Gya918 Conclusions and first question http://www.youtube.com/watch?v=7EuqKYKc6mg (then the small DVD ended, unfortunately :( ) at WSR10, Karlsruhe during GNURadio-dedicated session. Links to Presented Paper and Presentation Slides are attached to each video :-) best regards to everybody vincenzo -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Disciplining daughterboard oscillator through external reference
Thank you Matt. vincenzo 2010/2/24 Matt Ettus > On 02/23/2010 04:18 AM, Vincenzo Pellegrini wrote: > >> Hi everybody, >> by performing some tests over the USRP2 platform equipped with RFX400 >> frontend, it appeared to us that external reference only disciplines >> motherboard clock without locking daughterboard oscillator. >> >> Is this assumption correct? >> If so, is there any possibility to have also the db local oscillator >> disciplined by the external 10 MHz reference. >> > > > You have an older RFX400. You can easily modify it so that the > daughterboard shares the motherboard clock by following the instructions > here: > > http://gnuradio.org/redmine/wiki/1/USRPClockingNotes > > Matt > -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Soft-DVB has a Brother. A Receiving, Brother. And Fast...
Hi Achilleas, sorry for the belated reply but I was very busy working on extending MA over SR-DVB and with other academic stuff here. MA actually stands for "Memory Acceleration" and is intended as an optimization technique aimed at signal-processing-generated computation over GPPs and DSPs (we haven't explored it yet, but I'm persuaded that it can be useful for FPGA implementations too). Such optimization technique belongs to the broader class known in computer science as space/time trade-off and basically consists of an "algorithmic toolbox" which takes a classical implementation of a typical communication signal processing algorithm (say for example an OFDM time and frequency offset estimator or a Viterbi Decoder, just to quote two highly heterogeneous algorithms we've been trying) and returns a "memory-accelerated" version capable of running much faster over the same HW. Just as an example: since my last email upon this topic we applied MA to another (very small) section of SR-DVB chain and managed to further reduce the computational cost of the entire system previously shown in http://www.youtube.com/watch?v=S5nGBDCxhmk by an additional 2%. This appears to confirm our idea that considerable margins do exist for optimization as most of the chain is currently still implemented in a traditional way. I hope I have answered your question, even if with some delay. I will present some more details about this next week in Karlsruhe at WSR10. my best regards vincenzo On Mon, 2010-02-01 at 14:30 -0500, Achilleas Anastasopoulos wrote: > Vincenzo, > > this seems very impressive! > > May I ask what the initials NA stand for? > > best, > Achilleas > > > ___ > 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] Disciplining daughterboard oscillator through external reference
Hi everybody, by performing some tests over the USRP2 platform equipped with RFX400 frontend, it appeared to us that external reference only disciplines motherboard clock without locking daughterboard oscillator. Is this assumption correct? If so, is there any possibility to have also the db local oscillator disciplined by the external 10 MHz reference. thanks vincenzo -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Soft-DVB has a Brother. A Receiving Brother. And Fast...
Hi Per, carrier freq is 809.5 MHz (one of the Australian DVB-T center freqs in UHF) Phase and frequency responses are compensated by applying estimations done based on the (many) DVB-T OFDM pilot carriers. We do not average channel estimates to remove noise, still we get very clean constellation when doing lab tests. As well as useful constellations with SNR being around 12 dB. regards vincenzo 2010/2/1 Per Zetterberg > Vincenzo Pellegrini wrote: > >> SR-DVB demo video on youtube >> >> http://www.youtube.com/watch?v=S5nGBDCxhmk >> >> regards >> >> vincenzo >> >> >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > Nice. > > I am curious. What is the carrier frequency ? > > Do you do anything to combat phase-noise ? > > BR/ > Per > -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Soft-DVB has a Brother. A Receiving Brother. And Fast...
SR-DVB demo video on youtube http://www.youtube.com/watch?v=S5nGBDCxhmk regards vincenzo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Soft-DVB has a Brother. A Receiving Brother. And Fast...
Yes Dave, it is absolutely safe. Actually going from DVB-T to DVB-S (version 1), roughly speaking, only requires removing some OFDM-related blocks, which means it makes the system computationally lighter.. :) Hi Alexander, Yes, I absolutely want to share MA-related knowledge with the software radio community, especially with gnuradio community. At the present moment, papers describing MA technology are undergoing academic review process. Paper accepted in Karlsruhe (WS10) features a brief section about MA and presentation there will do as well. If I could just decide, I would provide links to all these contents right now on the list, but I'm not sure I'm allowed to without consequences for my publications. I will check what I actually can do and possibly prepare some descriptive content for MA that I will post to this list. Can you provide advice on these publication copyright issues? For sure I will give updates regarding increases of computational efficiency that will be achieved by SR-DVB while applying MA to other sections of the receive chain (currently only Viterbi and OFDM synch have been implemented through MA). Thanks for your interest. I will do my best to be clear and detailed ASAP my best regards vincenzo 2010/1/29 Alexander Chemeris > Hi Vincenzo, > > That's interesting. > Can you point to some description or this "MAgic" technology? From your > description I'm not sure I understand even on what level it works and what > it actually does :) > > On Fri, Jan 29, 2010 at 12:04, Vincenzo Pellegrini > wrote: > > Hi GNURadio fellows, > > considering that this list has grown to something highly relevant in > > Software Defined Radio I thought it would have been a good idea to share > > here a few thoughts I've been having since long and as well as a result > that > > was just achieved. > > > > > > Since a few months after my first approach to SDR in 2006, > > I thought I picked up two major facts about the technology: > > .:. SDR infinite potential lying for sure in its flexibility but, even > more > > relevantly, in its ability to bypass > > the costly HW-level design stage which is embedded in any > traditional > > radio design/production process > > .:. Its equally infinite power-inefficiency compared to traditional, > > HW-implemented competitor technologies. > > In fact, ease of development as well as flexibility appear to be > > inversely proportional to power efficiency. > > The latter being in my opinion the reason for which SDR has been growing > for > > ages up to now but has never "exploded" as we could expect from a > technology > > cutting away a conspicuous part of the design costs of any radio system. > > Actually, flexibility and cost-efficiency, though considerable, do not > > appear to be sufficient motivation for accepting to upscale power > > requirements (at a given computational cost yielded by the implemented > > wireless standard) by a factor which typically is in [100 ; 300]. > > Whether right or wrong, by working with these thoughts in mind, during > the > > research I'm carrying on at the University of Pisa, Italy while doing my > PhD > > here, I developed a novel implementation technique targeted at > > software-implemented Signal Processing over General Purpose CPUs or DSPs > > which we (at DSPCoLa lab, http://dspcola.iet.unipi.it ) call "MA". > > Current research results have shown that MA was able to increase by > slightly > > more than one order of magnitude the power efficiency of a traditionally > > implemented (MA-free) SDR. > > > > By applying such "MA" technology to the ETSI DVB-T receiver chain with > the > > help of: > > Mario Di Dio (former master thesis student, now PhD Student at DSPCoLa) > > Luca ROSE(former master thesis student at DSPCoLa, now PhD student at > > Supélec Paris) > > we obtained the receiving companion of Soft-DVB: SR-DVB. > > Standing for Software Receiver - DVB, > > SR-DVB is a fully software (all signal processing is done in pure C++ > over > > the host computer) ETSI DVB-T receiver capable of running realtime > > while providing 11.612 Mbps throughput > > and absorbing less than 50% of computational resources available over an > > Intel Q9400, 2.66 GHz CPU. > > As long as MA was applied only to the two computationally-heaviest blocks > of > > the receive chain (i.e. Viterbi Decoding and OFDM synch), we believe that > > considerable margins for improvement of the presented result do exist. > They > > will be explored in the next months. > > > > SR-DVB will be
[Discuss-gnuradio] Soft-DVB has a Brother. A Receiving Brother. And Fast...
Hi GNURadio fellows, considering that this list has grown to something highly relevant in Software Defined Radio I thought it would have been a good idea to share here a few thoughts I've been having since long and as well as a result that was just achieved. Since a few months after my first approach to SDR in 2006, I thought I picked up two major facts about the technology: .:. SDR infinite potential lying for sure in its flexibility but, even more relevantly, in its ability to bypass the costly HW-level design stage which is embedded in any traditional radio design/production process .:. Its equally infinite power-inefficiency compared to traditional, HW-implemented competitor technologies. In fact, ease of development as well as flexibility appear to be inversely proportional to power efficiency. The latter being in my opinion the reason for which SDR has been growing for ages up to now but has never "exploded" as we could expect from a technology cutting away a conspicuous part of the design costs of any radio system. Actually, flexibility and cost-efficiency, though considerable, do not appear to be sufficient motivation for accepting to upscale power requirements (at a given computational cost yielded by the implemented wireless standard) by a factor which typically is in [100 ; 300]. Whether right or wrong, by working with these thoughts in mind, during the research I'm carrying on at the University of Pisa, Italy while doing my PhD here, I developed a novel implementation technique targeted at software-implemented Signal Processing over General Purpose CPUs or DSPs which we (at DSPCoLa lab, http://dspcola.iet.unipi.it ) call "MA". Current research results have shown that MA was able to increase by slightly more than one order of magnitude the power efficiency of a traditionally implemented (MA-free) SDR. By applying such "MA" technology to the ETSI DVB-T receiver chain with the help of: Mario Di Dio (former master thesis student, now PhD Student at DSPCoLa) Luca ROSE(former master thesis student at DSPCoLa, now PhD student at Supélec Paris) we obtained the receiving companion of Soft-DVB: SR-DVB. Standing for Software Receiver - DVB, SR-DVB is a fully software (all signal processing is done in pure C++ over the host computer) ETSI DVB-T receiver capable of running realtime while providing 11.612 Mbps throughput and absorbing less than 50% of computational resources available over an Intel Q9400, 2.66 GHz CPU. As long as MA was applied only to the two computationally-heaviest blocks of the receive chain (i.e. Viterbi Decoding and OFDM synch), we believe that considerable margins for improvement of the presented result do exist. They will be explored in the next months. SR-DVB will be presented in Karlsruhe at WSR 10 as the article: "A Fully Software ETSI DVB-T Receiver Based on the USRP" during such presentation also MA technology will be briefly outlined. A demo video of our proof-of-concept receiver is available at www.legalepellegrini.it/ing/SR-DVB_demo_long.VRO as usual, mplayer or VLC wil play this camcorder mpeg2 viedo easily. Best regards to all writers and readers of the list vincenzo -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] WBX
Hi Matt... first, congratulations for the jewel.. :) 50 M --> 2.2 G wow.. :) how many do you have in stock? do you expect to run out of WBXes within the next few days? vincenzo 2010/1/14 Firas Abbas > Hi, > > > > > From: Matt Ettus > > > > At long last, the WBX is now available. > > > Great news. > > > > > > More details and more detailed specs will follow in the next few days. > > Sorry, cannot wait !!. > > Ettus website says it is full duplex. Gnuradio code says it is half-duplex. > Which one is right? > > > > > > Best Regards, > > Firas > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Vincenzo Pellegrini ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] libusrp2 tuning method
Hi everybody, Just a very quick question: I'm developing a simple interface to usrp2 directly using libusrp2. I'm calling the set _center_freq method and I'm having the same frequency offset problems (dxc not set) that you have with usrp1 when you don't use the u.tune() method. Problem is I could not find any similar method within libusrp2. Just could identify the set _center_freq one. Can anyone provide a pointer? Thanks and best regards vincenzo :-) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [Viterbi decoder]
Hi everybody, just if someone has tried: what is the maximum throughput that has been reached on current systems with gr's Viterbi implementation with let's say K=7 ? thank you vincenzo 2009/8/21 Achilleas Anastasopoulos : > If you are using the viterbi decoder from gr_trellis then definitely there > IS a way to use it without any modulation: that was the whole idea behind > writing all this using the "fsm" structure. > > All you need to define is the trellis on which the Viterbi algorithm will > work and the "costs" (ie, distances) between the true paths and > the observed ones. > > Achilleas > > > == > From: Rita's pfc > Subject: [Discuss-gnuradio] [Viterbi decoder] > To: Discuss-gnuradio@gnu.org > Message-ID: <24921515.p...@talk.nabble.com> > Content-Type: text/plain; charset=us-ascii > > > Is there any way to use the viterbi decoder without using any modulation? > I read the documentation and it seems that there is no way, but I want to be > sure that there isn't any possibility. > Thank you > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Vincenzo Pellegrini ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] DVB-T
you can open the .VRO with mplayer it's just mpeg2 as it comes out of a sony dvd camera :-) I will release the patched ffmpeg, however the modification is indeed very simple, I just added multi channel TS support, to the already existing TS container functionality. any good programmer can do a much better job than I did on this.. ;) regards vincenzo 2009/8/12 Rafael Diniz Ciao Vince, > Great to listen this good news! > > Some questions: > What kind of file is this (.VRO)? > Where can I find the ffmpeg patches? > > Rafael Diniz > > > sorry for previous mistake > > www.legalepellegrini.it/ing/quick-dvb-in-newRADIO.VRO > > > > 2009/8/12 Vincenzo Pellegrini : > >> Hi Matt, > >> here are the links to the old stuff: > >> > >> the article at the Karlsruhe conference > >> www.legalepellegrini.it/ing/PellegriniBacciLuise_WSR08_CR.pdf > >> > >> the demo there > >> www.legalepellegrini.it/ing/Soft-DVB-Karlsruhe.mp4 > >> > >> an ofdm file ready to be sent over the air with gr and the usrp > >> www.legalepellegrini.it/ing/ofdm_40.dump > >> > >> some new demo stuff, that is soft-dvb within a new sdr framework of my > >> own, > >> a modified version of ffmpeg, a smart buffer to make ffmpeg's output > >> CBR, an UDP/IP encapsulation layer and other stuff that I did to be > >> able to implement an entire tv broadcasting station in pure software > >> over 1 or 2 host PCs > >> www.legalepellegrini.it/quick-dvb-in-newRADIO.VRO > >> > >> this instead is the DVB-T receiver project ( 8MHz channel over the > >> USRP 1!!) that I'm doing at Pisa University with some Master Thesis > >> studentas that are working with me > >> www.legalepellegrini.it/ing/SR-DVBT_Project_Status_Brief2.pdf > >> www.legalepellegrini.it/ing/1stReceivedTS.png > >> > >> the receiver works pretty good but it is now still far from realtime. > >> We have reasonable hopes to take it to realtime on ordinary COTS HW. > >> > >> Sourcecode of soft-dvb is not currently available as I'm evaluating > >> possibilities for some commercial usage of it, within the independent > >> framework. Still I believe that resources like these.. especially > >> signal dumps can be of soime use to the gnuradio project. > >> > >> BTW > >> I'm now testing the whole thing over the usrp2.. > >> > >> regards > >> > >> vincenzo > >> > >> > >> > >> 2009/8/11 Matt Ettus > >>> > >>> > >>> I know that Vincenzo Pellegrini (and possibly others) had a working > >>> DVB-T implementation for GNU Radio, but all the links I find are dead. > >>> Can someone point me to the latest code or web page? > >>> > >>> Thanks, > >>> Matt > >>> > >>> > >>> > >>> ___ > >>> Discuss-gnuradio mailing list > >>> Discuss-gnuradio@gnu.org > >>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >> > >> > >> > >> -- > >> Vincenzo Pellegrini > >> > > > > > > > > -- > > Vincenzo Pellegrini > > > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > -- Vincenzo Pellegrini -- Vincenzo Pellegrini ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DVB-T
sorry for previous mistake www.legalepellegrini.it/ing/quick-dvb-in-newRADIO.VRO 2009/8/12 Vincenzo Pellegrini : > Hi Matt, > here are the links to the old stuff: > > the article at the Karlsruhe conference > www.legalepellegrini.it/ing/PellegriniBacciLuise_WSR08_CR.pdf > > the demo there > www.legalepellegrini.it/ing/Soft-DVB-Karlsruhe.mp4 > > an ofdm file ready to be sent over the air with gr and the usrp > www.legalepellegrini.it/ing/ofdm_40.dump > > some new demo stuff, that is soft-dvb within a new sdr framework of my own, > a modified version of ffmpeg, a smart buffer to make ffmpeg's output > CBR, an UDP/IP encapsulation layer and other stuff that I did to be > able to implement an entire tv broadcasting station in pure software > over 1 or 2 host PCs > www.legalepellegrini.it/quick-dvb-in-newRADIO.VRO > > this instead is the DVB-T receiver project ( 8MHz channel over the > USRP 1!!) that I'm doing at Pisa University with some Master Thesis > studentas that are working with me > www.legalepellegrini.it/ing/SR-DVBT_Project_Status_Brief2.pdf > www.legalepellegrini.it/ing/1stReceivedTS.png > > the receiver works pretty good but it is now still far from realtime. > We have reasonable hopes to take it to realtime on ordinary COTS HW. > > Sourcecode of soft-dvb is not currently available as I'm evaluating > possibilities for some commercial usage of it, within the independent > framework. Still I believe that resources like these.. especially > signal dumps can be of soime use to the gnuradio project. > > BTW > I'm now testing the whole thing over the usrp2.. > > regards > > vincenzo > > > > 2009/8/11 Matt Ettus >> >> >> I know that Vincenzo Pellegrini (and possibly others) had a working DVB-T >> implementation for GNU Radio, but all the links I find are dead. Can someone >> point me to the latest code or web page? >> >> Thanks, >> Matt >> >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > -- > Vincenzo Pellegrini > -- Vincenzo Pellegrini ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DVB-T
Hi Matt, here are the links to the old stuff: the article at the Karlsruhe conference www.legalepellegrini.it/ing/PellegriniBacciLuise_WSR08_CR.pdf the demo there www.legalepellegrini.it/ing/Soft-DVB-Karlsruhe.mp4 an ofdm file ready to be sent over the air with gr and the usrp www.legalepellegrini.it/ing/ofdm_40.dump some new demo stuff, that is soft-dvb within a new sdr framework of my own, a modified version of ffmpeg, a smart buffer to make ffmpeg's output CBR, an UDP/IP encapsulation layer and other stuff that I did to be able to implement an entire tv broadcasting station in pure software over 1 or 2 host PCs www.legalepellegrini.it/quick-dvb-in-newRADIO.VRO this instead is the DVB-T receiver project ( 8MHz channel over the USRP 1!!) that I'm doing at Pisa University with some Master Thesis studentas that are working with me www.legalepellegrini.it/ing/SR-DVBT_Project_Status_Brief2.pdf www.legalepellegrini.it/ing/1stReceivedTS.png the receiver works pretty good but it is now still far from realtime. We have reasonable hopes to take it to realtime on ordinary COTS HW. Sourcecode of soft-dvb is not currently available as I'm evaluating possibilities for some commercial usage of it, within the independent framework. Still I believe that resources like these.. especially signal dumps can be of soime use to the gnuradio project. BTW I'm now testing the whole thing over the usrp2.. regards vincenzo 2009/8/11 Matt Ettus > > > I know that Vincenzo Pellegrini (and possibly others) had a working DVB-T > implementation for GNU Radio, but all the links I find are dead. Can someone > point me to the latest code or web page? > > Thanks, > Matt > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Vincenzo Pellegrini ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] CUDA GPU Vs CELL BE
Hi everybody, I have recently had a look at two possibilities for SWRadio-aimed intensive computing, which i guess are the two main development lanes for our kind of stuff: .:. Cell BE platform .:. CUDA & nVidia GPUs I think this list is the best place to for a discussion on PROs and CONs of the two solutions, but couldn't find any by searching the mailing list. has this been discussed already? regards to all gr-fellows vincenzo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] max throughput USB 2.0
Maximum sustained throughput that we have achieved so far, given our chipsets and the USRP's cypress usb interface is 32 MB/sec that yields, at 16 bit sample resolution: 32M / (2 *2) = 8Msps (complex) ==>8MHz bandwidth (Nyquist) 1 factor 2 is for I+Q channels the other is for 16bit (=2bytes) sample resolution of course, at the price of halving sample resolution you can get double bandwidth vincenzo feldmaus > Hi All, > > i read the FAQ and the Documentation, but i got some questions > about the maximum throughput. > > For the ADC which has 64MHz we get 32MHz if we follow nyquist criteria. > The Documentation tell us the maximum speed results in 32MByte/s. > How do you come from 32MHz to 32Mbyte/s ? > > I believe this facts are based on 1Byte pro Time is this correct ? > this means you can only send 1 Byte per Time over USB 2.0 ? > Sorry i am not very familiar with the USB protocol. > > The USB 2.0 support 480MBit/s that are 60MByte/s. > So i think the USB 2.0 is not the bottle-neck ? > > If USB supports 2Byte pro Time we get (32MHz*(2Byte pro Time))=64MByte/s ? > But this could be result in Problems with synchronous/asynchronous ? > > Regards Markus > > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Vincenzo Pellegrini ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] synchronization throughout flowgraph
Crystal clear.. :-) thank you Tom 2009/3/11 Tom Rondeau > On Tue, Mar 10, 2009 at 6:48 AM, Vincenzo Pellegrini > wrote: > > Thanks Tom, > > > > I had looked at it. > > I still have a question. > > > > It looks to me like the blocks down the line receive data from the upper > > ones and do noting with that data (so the state of block's local variable > is > > frozen) but, I mean, there still is data flowing in and out those blocks. > > > > Is this assumption right? > > > > thanks > > again > > > > vincenzo > > Yes, data still flows into the blocks. But, we tell the scheduler that > we have consumed all of the incoming data, but we do not produce any > output data unless the signal line has triggered. This, then, drops > the data from the incoming stream. So data can flow all day long and > be ignored until the trigger line goes high. > > Tom > > > > > > > 2009/3/9 Tom Rondeau > >> > >> On Sun, Mar 8, 2009 at 8:20 PM, Vincenzo Pellegrini > >> wrote: > >> > Hi everybody, > >> > just a very simple question: > >> > is there a clean way in GNURadio to do this > >> > > >> > source-->block1-->block2 > >> > > >> > where: > >> > source sends let's say some gr_complex > >> > block 1 looks for some synchro signal within the flow > >> > > >> > block2 does absolutely nothing (i.e. does not process zeors or > anything, > >> > simply it is frozen) untill block1 says: "well your frame starts here" > >> > and > >> > delivers a vector for block 2 to work upon. > >> > > >> > It would be great if any body who's been doing this sort of things > could > >> > provide some pointer to start from. > >> > > >> > thank you all > >> > > >> > vincenzo > >> > > >> > PS. > >> > If this is not a sane way to arrange a flowgraph for doing > >> > syncronization, > >> > please point me to the sane way... ;-) > >> > Maybe I should only use stream-oriented blocks that decide what to do > >> > and > >> > when, just based on some block internal state? > >> > >> Look at the OFDM code. We did something similar where the data went > >> out port 0 and a flag signal out of port 1. The other guys down the > >> line would not do anything until they saw the flag signal go high. > >> > >> Tom > > > > > > > > -- > > Vincenzo Pellegrini > > > -- Vincenzo Pellegrini ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] synchronization throughout flowgraph
Thanks Tom, I had looked at it. I still have a question. It looks to me like the blocks down the line receive data from the upper ones and do noting with that data (so the state of block's local variable is frozen) but, I mean, there still is data flowing in and out those blocks. Is this assumption right? thanks again vincenzo 2009/3/9 Tom Rondeau > On Sun, Mar 8, 2009 at 8:20 PM, Vincenzo Pellegrini > wrote: > > Hi everybody, > > just a very simple question: > > is there a clean way in GNURadio to do this > > > > source-->block1-->block2 > > > > where: > > source sends let's say some gr_complex > > block 1 looks for some synchro signal within the flow > > > > block2 does absolutely nothing (i.e. does not process zeors or anything, > > simply it is frozen) untill block1 says: "well your frame starts here" > and > > delivers a vector for block 2 to work upon. > > > > It would be great if any body who's been doing this sort of things could > > provide some pointer to start from. > > > > thank you all > > > > vincenzo > > > > PS. > > If this is not a sane way to arrange a flowgraph for doing > syncronization, > > please point me to the sane way... ;-) > > Maybe I should only use stream-oriented blocks that decide what to do and > > when, just based on some block internal state? > > Look at the OFDM code. We did something similar where the data went > out port 0 and a flag signal out of port 1. The other guys down the > line would not do anything until they saw the flag signal go high. > > Tom > -- Vincenzo Pellegrini ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] synchronization throughout flowgraph
Hi everybody, just a very simple question: is there a clean way in GNURadio to do this source-->block1-->block2 where: source sends let's say some gr_complex block 1 looks for some synchro signal within the flow block2 does absolutely nothing (i.e. does not process zeors or anything, simply it is frozen) untill block1 says: "well your frame starts here" and delivers a vector for block 2 to work upon. It would be great if any body who's been doing this sort of things could provide some pointer to start from. thank you all vincenzo PS. If this is not a sane way to arrange a flowgraph for doing syncronization, please point me to the sane way... ;-) Maybe I should only use stream-oriented blocks that decide what to do and when, just based on some block internal state? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Broken USRP report
I was told by Matt to run an executable you can find within the trunk. It rewrote the eeprom and solved the problem. I suppose it was this one.. but I'm not sure as it seems to target daughterboards instead of the motherboard... /usrp/host/apps/burn-db-eeprom Please ask the list for confirmation about this... best regards to all vincenzo 2009/2/16 > Hi Vincenzo, > I'm Thu from Hanoi, Vietnam. After working with the USRP for 2 weeks I have > the same problem with you. The LED is off while the fan is running and the > fuse F501 is OK. > > How about you and what happened with your USRP? > > Vincenzo Pellegrini wrote: > > > > Hi everybody, > > > > I've got really no idea of what happened.. I have been working a few > > hours with my USRP, then I switched it off for about an hour. Then I > > came back, re-plugged power into it and I got 'Unable to find USRP#0'. > > > > I checked the led and it was not flashing. > > > > The fuse F501 seems ok (I can still measure a 6V tension past it with my > > tester) > > > > The fan spins as always. > > > > It's quite a new bought one: Ser=2687 > > > > Can anyone help with suggestion to figure out the problem? > > > > thanks > > > > vincenzo > > > > > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > Quoted from: > http://www.nabble.com/Broken-USRP-report-tp17870105p17870105.html > > -- Vincenzo Pellegrini ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Soft-DVB DVB-T transmitter
Sure rafael. I'm also looking forward to be able to buy my own WB50... Is it availale yet? If not, you know when will it be? 2008/11/12, rafael2k <[EMAIL PROTECTED]>: > Hello people, > I'm following the discussion about the Soft-DVB, and I'm thinking about use > of > the WBX0510 daughterboard (50 MHz to 1 GHz) w/ Soft-DVB - Will then be > possible to transmitt in any VHF/UHF channel? > > Bye, > Rafael Diniz > > Em Tuesday 11 November 2008, Vincenzo Pellegrini escreveu: >> Martin , >> sorry for the delay. My exams seem to have gone well even if it's not >> official yet. I also had to do a demo for a company I have a temporary >> contract with for developing some gnuradio based gsm-r security >> sentinels. Also the demo was smooth. (i already listed the project on >> the gnuradio wiki) >> so i really hope i'll be able to prepare the 8Mhz stream for you >> within the next 2/3 days. Would this still be useful? >> >> 2008/11/3, Martin DvH <[EMAIL PROTECTED]>: >> > On Mon, 2008-11-03 at 14:13 +0100, Martin DvH wrote: >> >> >> >> >> >> > Van: [EMAIL PROTECTED] >> >> >> >> [mailto:[EMAIL PROTECTED] >> >> Namens Vincenzo Pellegrini >> >> >> >> > Verzonden: maandag 3 november 2008 0:16 >> >> > Aan: Martin DvH >> >> > CC: discuss-gnuradio >> >> > Onderwerp: [Discuss-gnuradio] Re: Soft-DVB DVB-T transmitter >> >> > >> >> > >> >> > This is Great... :) >> >> > >> >> > Yup, the playback cannot be smooth because of the wrong throughput, >> >> >> >> definitely. >> >> >> >> > Did you use the USRP1 with interpolation factor = 16 ? >> >> >> >> Yes I did. >> >> >> >> > I can prepare a modulated signal with the correct throughput for >> >> >> >> you.. this is not a problem... :) >> >> >> >> Please do, this would be great. >> >> >> >> > what hard disc are you playing your signal back from? >> >> >> >> Internal 2.5" harddisk of my acer 6930 notebook (Aspire 6930G-734G32BN >> >> LX.AVB0X.135) >> >> 2.5" 320GB HDD 5400rpm, SATA >> > >> > I checked now. It is a: >> > Western digital Scorpio 320 GB SATA (WDC WD3200BEVT-22ZCT0) >> > 2.5-inch SATA Hard Drive 320 GB, 3 Gb/s, 8 MB Cache, 5400 RPM >> > >> > Benchmark from tomshardware (h2benchw 3.6): >> > http://www.tomshardware.com/charts/2-5-hard-drive-charts/Minimum-Read-Tra >> >nsfer-Performance,687.html minimum read transfer rate 33.5 MB/sec >> > average read transfer rate 52.2 MB/sec >> > maximum read transfer rate 68.2 MB/sec >> > >> >> I am not at home right now So I can't check the exact brand and model >> >> of >> >> the >> >> harddisk. >> >> It can do around 38 MB/sec so this is just enough (required 32 MB/sec) >> >> >> >> I also have 4GB of memory in this notebook, so I think it will buffer >> >> the complete file. >> >> >> >> I had to use my notebook because with my desktop PC (ASrock >> >> 939-DUAL-SATA2) >> >> The USB TX bandwidth is less then 32 MB/sec. >> >> (Which is strange because I CAN receive 32 MB/sec) >> >> I get UuUuUu on this machine when useing interpolation 16, so unusable. >> >> >> >> Regards, >> >> Martin >> >> >> >> > regards >> >> > >> >> > vincenzo >> >> > >> >> > >> >> > 2008/11/3 Martin DvH <[EMAIL PROTECTED]> >> >> >> >> Hi, >> >> >> >> > > In fact: 8 complex Msps implement a 7 MHz channel while >> >> >> >> 9.142857143 >> >> >> >> > > complex Msps implement an 8 MHz channel. >> >> > > Just try to go as close as possible to such sampling >> >> >> >> frequency by >> >> >> >> > > using USRP2 and let me know what happens... it could >> >> >> >> turn out that we >> >> >> >> > > need a resampler block. >> >> > >> >> > So if I use a fractional rate resampler with interpolation >> >>
[Discuss-gnuradio] Re: Soft-DVB DVB-T transmitter
Martin , sorry for the delay. My exams seem to have gone well even if it's not official yet. I also had to do a demo for a company I have a temporary contract with for developing some gnuradio based gsm-r security sentinels. Also the demo was smooth. (i already listed the project on the gnuradio wiki) so i really hope i'll be able to prepare the 8Mhz stream for you within the next 2/3 days. Would this still be useful? 2008/11/3, Martin DvH <[EMAIL PROTECTED]>: > > On Mon, 2008-11-03 at 14:13 +0100, Martin DvH wrote: >> >> >> >> >> >> >Van: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] >> Namens Vincenzo Pellegrini >> >Verzonden: maandag 3 november 2008 0:16 >> >Aan: Martin DvH >> >CC: discuss-gnuradio >> >Onderwerp: [Discuss-gnuradio] Re: Soft-DVB DVB-T transmitter >> > >> > >> >This is Great... :) >> > >> >Yup, the playback cannot be smooth because of the wrong throughput, >> definitely. >> >Did you use the USRP1 with interpolation factor = 16 ? >> Yes I did. >> > >> >I can prepare a modulated signal with the correct throughput for >> you.. this is not a problem... :) >> > >> Please do, this would be great. >> >what hard disc are you playing your signal back from? >> >> Internal 2.5" harddisk of my acer 6930 notebook (Aspire 6930G-734G32BN >> LX.AVB0X.135) >> 2.5" 320GB HDD 5400rpm, SATA > I checked now. It is a: > Western digital Scorpio 320 GB SATA (WDC WD3200BEVT-22ZCT0) > 2.5-inch SATA Hard Drive 320 GB, 3 Gb/s, 8 MB Cache, 5400 RPM > > Benchmark from tomshardware (h2benchw 3.6): > http://www.tomshardware.com/charts/2-5-hard-drive-charts/Minimum-Read-Transfer-Performance,687.html > minimum read transfer rate 33.5 MB/sec > average read transfer rate 52.2 MB/sec > maximum read transfer rate 68.2 MB/sec > > > >> I am not at home right now So I can't check the exact brand and model of >> the >> harddisk. >> It can do around 38 MB/sec so this is just enough (required 32 MB/sec) >> >> I also have 4GB of memory in this notebook, so I think it will buffer the >> complete file. >> >> I had to use my notebook because with my desktop PC (ASrock >> 939-DUAL-SATA2) >> The USB TX bandwidth is less then 32 MB/sec. >> (Which is strange because I CAN receive 32 MB/sec) >> I get UuUuUu on this machine when useing interpolation 16, so unusable. >> >> Regards, >> Martin >> >> > >> >regards >> > >> >vincenzo >> > >> > >> >2008/11/3 Martin DvH <[EMAIL PROTECTED]> >> >> >> >> Hi, >> >> > > In fact: 8 complex Msps implement a 7 MHz channel while >> 9.142857143 >> > > complex Msps implement an 8 MHz channel. >> > > Just try to go as close as possible to such sampling >> frequency by >> > > using USRP2 and let me know what happens... it could >> turn out that we >> > > need a resampler block. >> > So if I use a fractional rate resampler with interpolation >> factor >> > 10/8=1.25 I get a 7 Mhz channel with 10 Msps samplerate. >> > If I use a fractional rate resampler with interpolation >> factor >> > 10/9.142857143=1.09375 I get a 8 Mhz channel with 10 Msps >> samplerate >> > >> > If I use a fractional rate resampler with DECIMATION >> factor >> > 9.142857143/8=8/7=1.142857143 I get a 8 Mhz channel with 8 >> Msps >> > samplerate with the out-of-band skirts folded back at the >> sides. >> > >> > Would be interesting to see if this last one works with a >> USRP1. >> > >> > I'll let you know how the experiments go. >> >> I resampled and scaled your ofdm_40.dump file so it now will >> use 8 Mhz bandwidth with a 8 Msps samplerate. >> The reception never can be perfect this way but it seems >> good enough for >> tests. >> >> My USB DVB-T receiver receives the transport stream without >> problems. >> Mplayer playes the stream without problem for two loops and >> then crashes >>
[Discuss-gnuradio] Re: Soft-DVB DVB-T transmitter
d you make a stream with 10 Msamples/sec samplerate and 8 > > > Mhz wide channel. > > > This way I can use standard standalone DVB-T receivers and > > > don't have the 7Mhz bandwith on UHF problem. > > > > > > For the 10 Msps stream I would have to use my USRP2 to output > > > it. > > > It has a 100 Mhz DAC (in stead of 64 Msps in the USRP1) > > > It has a gbit ethernet connection for the samples, so I can go > > > up to 25 Msps. > > > It can only do fixed interpolation rates so I have to choose > > > from the table below. > > > (8 Msamples/sec is not supported on the USRP2) > > > > > > > > > USRP2 > > > dac_rateinterp ethernet_sample_rate > > > 100 4 25 > > > 100 5 20 > > > 100 6 16.67 > > > 100 7 14.29 > > > 100 8 12.5 > > > 100 9 11.11 > > > 100 10 10 <I think 10 Msamples/sec > > > should be optimal > > > 100 11 9.09 > > > 100 12 8.33 > > > 100 13 7.69 > > > 100 14 7.14 > > > > > > > > > I think 10 Msamples/sec would be a good candidate. > > > > > > Have you also tried using 8 Msamples/sec on the USRP1? > > > I know there would be no room left for IF channel filtering, > > > but it could in theory still work. > > > If this works I would also very much appreciate a 8Mhz > > > bandwidth stream with 8 MSPS samplerate so I can demonstrate > > > with a standard USRP1. > > > > > > Thanks for your help so far. > > > I appreciate it very much. > > > > > > And good luck with your exams. > > > > > > Have a nice weekend. > > > > > > Greetings, > > > Martin > > > > > > > > > > > > > > > -- > > > Vincenzo Pellegrini > > -- Vincenzo Pellegrini ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] C++ to python
Hi everybody, suppose I have a python application with gui, what is the best way to provide some data (a few floats every second) back from C++ to my python gui flow graph? Really Thanks vincenzo -- Vincenzo Pellegrini ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Soft-DVB DVB-T transmitter
Hi Martin, sorry for the delayed replies but now I've passed my first cluster of PhD tests (went well) and I've got to carry out some work + preparing the second group of tests. Well, really glad to know that you managed to receive my signals. Yup dvb-t sticks can actually receive 7 MHz channels everywhere, Well, actually any DVB-T chipset can but typically manufacturers impose strange limitations on set-top-boxes such as "7 MHz chanels accepted only in VHF" I don't really know why. The signal I provided you with is suitable for both 7 and 8 MHz channels without any modification needed. The only thing you have to do is to set your sampling frequency a bit higher. this should be possible with USRP2. In fact: 8 complex Msps implement a 7 MHz channel while 9.142857143 complex Msps implement an 8 MHz channel. Just try to go as close as possible to such sampling frequency by using USRP2 and let me know what happens... it could turn out that we need a resampler block. more details will follow as soon as I find some time... best regards and greetings to all fellow GNURadioers vincenzo PS Rafael, just have a look back a this thread and you'll find all the info you need to do your test broadcast. Thanks for your interest 2008/10/31 Martin Dudok van Heel <[EMAIL PROTECTED]> > Hi Vincenzo. > How are things going with your exams. > > I hope well. > > Thanks for your help so far. > > I finally got your DVB-T dump streams working. > I first tried using an undersampled basicTX but never got it to work. > (use a niquist mirror in the VHF range on channel 11 or 12 (219.5 Mhz or > 226.5 Mhz)) > > I now use a RFX900 and that works with a pinnacle PCTV-Solo 72e usb DVB-T > receiver card plugged into my PC. > I use 858.0 Mhz (channel 69) > I used a 10 dB attenuator on the antenna output to limit output power. > I also modified the RFX900 to enable transmitting outside of the ISM band. > (disable saw-filter. add 220 pF capacitor) > > Apparantly the pinnacle 72e can receive 7 Mhz channels on the UHF channels. > My standalone settopbox DVB-T receiver can't handle it. > > I noticed you don't use the full possible range in your 16 bit streams. > (only goes from -80 to +80 while you could use -8192 to 8192) > Is this on purpose? > I can multiply samples by 64 and get a cleaner signal. (But also more > output power) > > > I do have a request, I hope it is not too much work. > Could you make a stream with 10 Msamples/sec samplerate and 8 Mhz wide > channel. > This way I can use standard standalone DVB-T receivers and don't have the > 7Mhz bandwith on UHF problem. > > For the 10 Msps stream I would have to use my USRP2 to output it. > It has a 100 Mhz DAC (in stead of 64 Msps in the USRP1) > It has a gbit ethernet connection for the samples, so I can go up to 25 > Msps. > It can only do fixed interpolation rates so I have to choose from the table > below. > (8 Msamples/sec is not supported on the USRP2) > > > USRP2 > dac_rateinterp ethernet_sample_rate > 100 4 25 > 100 5 20 > 100 6 16.67 > 100 7 14.29 > 100 8 12.5 > 100 9 11.11 > 100 10 10 <I think 10 Msamples/sec should be > optimal > 100 11 9.09 > 100 12 8.33 > 100 13 7.69 > 100 14 7.14 > > > I think 10 Msamples/sec would be a good candidate. > > Have you also tried using 8 Msamples/sec on the USRP1? > I know there would be no room left for IF channel filtering, but it could > in theory still work. > If this works I would also very much appreciate a 8Mhz bandwidth stream > with 8 MSPS samplerate so I can demonstrate with a standard USRP1. > > Thanks for your help so far. > I appreciate it very much. > > And good luck with your exams. > > Have a nice weekend. > > Greetings, > Martin > > -- Vincenzo Pellegrini ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Soft-DVB DVB-T transmitter
Hi Martin, thanks for the FTP. I already have a location online at my father's lawyer's office. So, there you can find all old posted videos (which won't get removed for the foreseeable future) and some new, more descriptive ones: PREFIX= www.legalepellegrini.it/ing/ and then: Soft-DVB-Karlsruhe.mp4//the video of the conference we met at ofdm_RAI_MUXA2.dump//a training DVB-T OFDM signal for receivers that want "broadcast-level" channel tables. allows you to teach the receiver on what pids to look for channels when you send the real signal ofdm_40.dump //a signal with some content within (if your receiver is smart enough this is the only thing you have to send) @Grandmas.mp4 //an on the air broadcast with RFX900 at a 30odd meters distance with 5 concrete and brick walls within signals are interleaved short samples (I/Q) with sampling frequency 8Msps the receiver must therefore be able to receive a 7 MHz channel the vast majority of DVBT receivers accept 7 MHz channels in VHF but only a few accept such channels in the UHF spectrum. I'm actually curious about the receivers that will be used within the demo you described.. I had to search intensively to find receivers capable of such an "oddity" and it turned out that all receivers built for Australian market, actually are. Any way as soon as Matt will provide the project with the promised sub-1GHz transceiver it will be possible to broadcast DVB-T signals towards almost any existing receiver. If you wold like signals carrying some other content I can help. But let's first test these signals. Currently I can prepare a signal with 2 or 3 standard resolution channels or up to 10 hand-held resolution channnels PS I decided to make this communication public because it contains a few resources that could even be useful for somebody within the project. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Oddities in trunk [EMAIL PROTECTED] - @8850]
OK, I've solved it. It was my fault as usual.. :-D > > Are you subclassing gr_sync_interpolator? YUP > > Are you overriding forecast in the same class? > NOPE what happened is that I mistook gr_sync_interpolator buggy behavior for a feature belonging to gnuradio. :-D It was indeed a useful feature for my purposes, and I built upon it. Before 8835, you could lock the value of noutput_items when using an interpolator by simply feeding into it a noutput_items-long vector. after 8335, this was no longer true and set me into troubles. right now, I'm overriding fixed_rate_ninput_to_noutput in order to obtain the same result. It works. (using set output multiple did not) If there's a better way, I'm eagerly listening. Still TPB scheduler does not work with Soft-DVB. Indeed I'm looking forward to parallelizing Soft-DVB code, and I need to understand more of all this. I'll look for references and direction on the wiki. Just a preliminary question. Do we have already the new scheduler working also on the cell? I mean would it just do on the PS3 the same parallelization it is doing un my intel dual core cpu? really thanks for support... I wouldn't have fixed the thing without your suggestions.. :-) vincenzo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Oddities in trunk [EMAIL PROTECTED] - @8850]
Oddities in trunk [EMAIL PROTECTED] - @8850] a few days ago I bought a new host system for my GNURadio development activities. Intel E8400 CPU, G35 express chipset. All tests with such machine were ok. Reported chipset throughputs were 32MB/s etc... Then I compiled and ran my Soft-DVB modulator code. It built successfully and the application seemed to work all right but the signal was not recognized by any of my receivers. I actually started blaming any single piece of the HW and tested all of them but nothing was wrong. at last I foud the problem to be the revision of the trunk I used. More precisely, using Exactly The Same Soft-DVB code on every revision I get: 1.all revisions provide flawless building and instantiation of Soft-DVB application 2.all revisions prior to 8800 have soft DVB producing a perfectly receivable signal 3.all revisions after 8850 have soft DVB producing a totally corrupted signal. currently I'm testing to see what could be the modification responsible for this and report that to the list... actually this effort of testing various trunk samples taken from the trunk evolution is quite time consuming... but I'll report any discovery to this list. If anybody has suggestions... they'd be enormously appreciated really thanks vincenzo PS I suspect something that has got to do with syncronization of computed output chunks.. but It's just a feeling and, indeed quite generic.. :( ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: libboost_thread-gcc43-mt-1_36.so.1.36.0
Ok, sorry for bothering. I understood my mistake by myself. I had forgotten to set the LD_LIBRARY_PATH environmental variable to the $BOOST__PREFIX/lib. Now my question is: I noticed that the load generated by my application is balanced between the two cores of my machine.. is there any way to go one step back (like a compiling option or something) and tell the system not to do so but concentrate the whole load just on one core? alternatively how can I get the previous trunk version, the one before introducing dependency on boost 1.35? thanks vincenzo 2008/9/3 Vincenzo Pellegrini <[EMAIL PROTECTED]> > I have followed instructions to download boost > 1.36 > > gnuradio compliled smoothly > I've got this problem now: the gnuradio applications I had previously > written compile flawlessly but, when the python script implementing the > application is started > I get: > > > from gnuradio import gr, eng_notation > File "/usr/local/lib64/python2.5/site-packages/gnuradio/gr/__init__.py", > line 43, in > from gnuradio_swig_python import * > File > "/usr/local/lib64/python2.5/site-packages/gnuradio/gr/gnuradio_swig_python.py", > line 23, in > from gnuradio_swig_py_runtime import * > File > "/usr/local/lib64/python2.5/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py", > line 6, in > import _gnuradio_swig_py_runtime > ImportError: libboost_thread-gcc43-mt-1_36.so.1.36.0: cannot open shared > object file: No such file or directory > FAIL: run_tests > > which currently I cannot understand.. > > what have I done wrong? > > thanks > > vincenzo > > > PS. > Eric, also thanks for the precious info about the PS3 chipset. > I think I'll wait for the USRP2 with its Gigabit Ethernet. Is Gb Eth. fine > on the PS3? > > -- Vincenzo Pellegrini ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] libboost_thread-gcc43-mt-1_36.so.1.36.0
I have followed instructions to download boost 1.36 gnuradio compliled smoothly I've got this problem now: the gnuradio applications I had previously written compile flawlessly but, when the python script implementing the application is started I get: from gnuradio import gr, eng_notation File "/usr/local/lib64/python2.5/site-packages/gnuradio/gr/__init__.py", line 43, in from gnuradio_swig_python import * File "/usr/local/lib64/python2.5/site-packages/gnuradio/gr/gnuradio_swig_python.py", line 23, in from gnuradio_swig_py_runtime import * File "/usr/local/lib64/python2.5/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py", line 6, in import _gnuradio_swig_py_runtime ImportError: libboost_thread-gcc43-mt-1_36.so.1.36.0: cannot open shared object file: No such file or directory FAIL: run_tests which currently I cannot understand.. what have I done wrong? thanks vincenzo PS. Eric, also thanks for the precious info about the PS3 chipset. I think I'll wait for the USRP2 with its Gigabit Ethernet. Is Gb Eth. fine on the PS3? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] PS3 USB chipset
Hi everybody, I'm planning to begin to learn and explore the fantastic territories of parallel computing applied to software radio that Eric is currently opening to us through his work on the Cell BE platform. (just by the way, thanks Eric!) Therefore, I will save some money to buy a PS 3 :-) I know It's not gonna be a easy way to go, but such a computational power is simply an incredible dream.. :-) So, my question: has anybody yet tested the outwards (host to USRP) throughput of the PS3 usb chipset? Is it able to cope with our fatal 32MB/s ? Thanks Vincenzo PS. Is anybody using an adapter to connect the PS3 video output to a standard VGA monitor? -- Vincenzo Pellegrini ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] rfx900 wiki edit
I was planning to edit the RFX900 wiki page like this, as promised in my previous email requiring info RFX900 gain I thought to submit the modification to the list before doing it thanks vincenzo = USRP Daugherboard: RFX900 = '''Specifications'''[[BR]] __RX__: 800MHz - 1000MHz [[BR]] __TX__: 800MHz - 1000MHz @ 200+mW [[BR]] http://www.ettus.com/images/Flex900.jpg The board features an ISM band filter that suppresses the RF signal outside the 902-928 MHz band and attenuates it within such band by one dB or two. If usage of the board outside the ISM band is required, the filter can be bypassed by cutting the traces to the filter FIL.1 and soldering a 100pF capacitor in parallel to it. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RFX 900 200mW
Hi everybody, just a simple question: does the RFX900 provide 200mW just out of the box? Do I have to take care of something in particular in order to obtain them? Actually, what are the appropriate gain values that I should pass to subdev.set_gain() n order to maximize correctly the output power? Sorry for bthering the list with such questions but I was unable to have them answered in the RFX900 section of the wiki.. maybe I'll add them myself once I'll have fully understood the issue.. thanks and regards to all -- Vincenzo Pellegrini ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Latest publications: about DAB and Soft-DVB
Hi Rafael, prego! yes the link is correct but the video isn't online yet because i've had a few sync problems with the transcoding. I'll send you an email as soon as it's online.. best regards vincenzo 2008/5/8 rafael2k <[EMAIL PROTECTED]>: > Ciao Vincenzo, > Grazie! > > Is the video link correct? > > Rafael Diniz > > Em Tuesday 06 May 2008, Vincenzo Pellegrini escreveu: > > Hi Rafael, > > you can find the paper here: > > http://wwvince.interfree.it/PellegriniBacciLuise_WSR08_CR.pdf > > > > thanks for your interest. > > > > soon (one or two days) there will also be a video of the presentation in > > Karlsruhe (including a live Soft-DVB demonstration) here: > > > > www.legalepellegrini.it/Soft-DVB-Karlsruhe.mp4 > > > > 2008/5/6 rafael2k <[EMAIL PROTECTED]>: > > > Hi all, > > > Can anyone make available the OFDM / DAB implementation by Jens Elsner, > > > which > > > original location was: > > > - http://www.1c3.de/gr-dab.tar.bz2 > > > > > > There is also a paper called: > > > - V. Pellegrini, G. Bacci, M. Luise, "Soft-DVB, a Fully Software, > > > GNURadio > > > Based ETSI DVB-T Modulator", in Proc. WSR'08, Karlsruhe, Germany, March > > > 2008 > > > > > > Can it be accessible via any University Online Library? > > > -- > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > Ciência da Computação @ Unicamp > Rádio Muda, radiolivre.org, TV Piolho, tvlivre.org, > www.midiaindependente.org > Chave PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2FF86098 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > -- Vincenzo Pellegrini ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Latest publications: about DAB and Soft-DVB
Hi Rafael, you can find the paper here: http://wwvince.interfree.it/PellegriniBacciLuise_WSR08_CR.pdf thanks for your interest. soon (one or two days) there will also be a video of the presentation in Karlsruhe (including a live Soft-DVB demonstration) here: www.legalepellegrini.it/Soft-DVB-Karlsruhe.mp4 2008/5/6 rafael2k <[EMAIL PROTECTED]>: > Hi all, > Can anyone make available the OFDM / DAB implementation by Jens Elsner, > which > original location was: > - http://www.1c3.de/gr-dab.tar.bz2 > > There is also a paper called: > - V. Pellegrini, G. Bacci, M. Luise, "Soft-DVB, a Fully Software, > GNURadio > Based ETSI DVB-T Modulator", in Proc. WSR'08, Karlsruhe, Germany, March > 2008 > > Can it be accessible via any University Online Library? > > > Thanks, > Rafael Diniz > @ Campinas University > > PGP Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2FF86098 > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- Vincenzo Pellegrini ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr.fft_vcc and FFTW
thanks Brian, sorry for having been so silly, I had just stopped 1 step away from the answer.. regards vincenzo On Wed, 2008-01-23 at 08:18 -0500, Brian Padalino wrote: > On Jan 23, 2008 7:50 AM, Vincenzo Pellegrini <[EMAIL PROTECTED]> wrote: > > hi, > > does gr.fft_vcc implement the FFTW algorithm? > > Looking here: > > > http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/lib/general/gr_fft_vcc.cc#L89 > > http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/lib/general/gr_fft_vcc.cc#L44 > > ... which points here: > > > http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/lib/general/gri_fft.cc#L124 > > Leads to the answer you seek. The power of Free Software is miraculous. > > Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr.fft_vcc and FFTW
hi, does gr.fft_vcc implement the FFTW algorithm? thanks vincenzo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Pentium IV computing power in FLOPS
Thanks Eric. very precious info.. just by the way.. on March 6th, the Soft-DVB work will be presented in Karlsruhe at the WSR08 software defined radio conference. greetings Vincenzo On Sun, 2008-01-20 at 20:19 -0800, Eric Blossom wrote: > On Mon, Jan 21, 2008 at 01:10:47AM +0100, Vincenzo Pellegrini wrote: > > Hi everybody, > > could anybody help me in figuring out what is (even a rough estimate is OK) > > the raw computing power of a 3.0GHz Pentium IV CPU? > > > > really thanks for help > > > > -- > > Vincenzo Pellegrini > > Assuming you're coding in assembler using SSE* instructions, you can > get a sustained throughput of about 1 FLOP / clock cycle. Since > you're not really doing that, I'd call the 3GHz P4 about 0.5 to 1.0 GFLOP. > > YMMV. Widely ;) > > On the netburst microarchitecture used in the P4 it's really hard to get > good floating point performance because of the very deep pipeline, > scarcity of registers, and so-so FPU. > > Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Pentium IV computing power in FLOPS
Hi everybody, could anybody help me in figuring out what is (even a rough estimate is OK) the raw computing power of a 3.0GHz Pentium IV CPU? really thanks for help -- Vincenzo Pellegrini ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] problem with http link to Soft-DVB video
if someone had problems with this link http://httpwww.interfree.it/Realtime_Soft-DVB.mp4 i guess it was just because the file was still being uploaded when I sent the email... now everything should be ok thanks vincenzo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Soft-DVB has reached realtime
hi list, I'm very happy to be able to communicate that Soft-DVB, my fully software, GNURadio based implementation of ETSI DVB-T digital television standard (EN 300 744) has reached full real time operating capabilities on a 3 years old, single core pentium4, 3 GHz. If we're lucky (a couple of things must go the right way with my undergrad academic activities here in Pisa, Italy :D) GNURadio will soon be able to include a fully functional DVB-T modulator... in this email you can find the link to a video of a trial DVB-T transmission lasting almost 13 minutes, which, if performed in virtual time, would require approximately 25GB of storage capacity, read at a stable rate of 32MBps. the high performance Seagate Barracuda disk, present in previous videos on top of the PC's metal case, has been removed to show that I'm making no use of high throughput storage devices... also,the video is very long, in order to show that what I'm sending out is not a pre-calculated loop but a single, realtime transmission in which the COFDM signal is calculated "on the fly" from the MPEG2 transport stream that is fed to the Soft-DVB application. the video is an h264 as usual thanks for reading... vincenzo http://httpwww.interfree.it/Realtime_Soft-DVB.mp4 ps tha file is very big.. but it's significant from the beginning.. so that one can stop downloading it aftere a while.. without losing the main points of it... ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio over PS3
Really thanks Robert, your answer was extremely useful, to get into the problem.. well, now my question becomes: let's say I have a gnuradio application entirely built using my own C++ blocks, as soon as I'll have mastered the required CellProcessor development skills, if I rewrite my C++ blocks in a way that is suitable for running them on the SPEs (i.e. breaking them into multiple synchronized threads), building them via the CellSDK, will my application actually use SPEs if run under the same Python script under Fedora X ? thanks vincenzo ps sorry for the duplicate mail. it was a mistake.. :D ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNURadio over PS3
hi everybody, It would be incredibly useful to me if somebody could suggest a link to some resources explaining all that has currently been achieved by using "GNURadio over Fedora over PS3", and how much advantage does the current GNURadio release take of the cell processor architecture. Is it necessary to rewrite our applications to have them efficiently running on the cell? really thanks in advance vincenzo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re:[Discuss-gnuradio] This python version requires swig to be run....
thanks Eric, thanks Matt.. it was my fault: I had forgotten to update the swig interface file path within configure.ac now everything is all right on both F7 and F8 best regards vincenzo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] This python version requires swig to be run....
Hi, I've just tried to compile my DVB-T application on a Fedora 7 system which has Python 2.5 instead of 2.4 installed. I get this: dvb.cc:139:20: error: Python.h: No such file or directory dvb.cc:2539:4: error: #error "This python version requires swig to be run with the '-classic' option" dvb.cc:2543:3: error: #error "This python version requires swig to be run with the '-nomodern' option" dvb.cc:2546:3: error: #error "This python version requires swig to be run with the '-nomodernargs' option" when I try to make check my code.. what am I doing wrong..? / where should I look to change necessary options to keep uo with Python changes? many thanks -- Vincenzo Pellegrini ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Soft-DVB working flawlessly
Hi, sorry I just have DVB-T at the moment.. for John Gilmore, I have just seen your email in GNURadio archive. For some strange reason i had missed it. Really thanks for your words of enthusiastic appreciation. Currently I'm cleaning the code with the purpose of approaching real-time on my current sempron-based single core pc. As soon as the code will be not just working but also clean and quick, I'll start a proper contribution procedure.. :) best regards vincenzo On Mon, 2007-11-26 at 09:50 -0800, John Clark wrote: > John Gilmore schrieb: > > I can already think of one use that others can make of your > > transmitter. EFF and I are interested in measuring the DRM responses > > of various digital television consumer products. DRM is the > > unnecessary restrictions that are built in to control what consumers > > can do. (Like no fast forwarding; won't play in some countries; or > > only works with one manufacturer's products.) DVB is really thick > > with complicated, ugly restrictions like "can only record one copy -- > > only on Tuesdays and only within 1000 meters or with members of your > > immediate family except for kids of divorced parents". I bet there is > > a lot of variation in the products that try to enforce it -- and maybe > > some don't even try. > > > > Those 'family' options will only be available after having you and yours > updated (apparently evolution never > thought of that option...) with intracranial RFID chips... > > > But that aside... having the ability to do DVB would then allow one to > modify the signal with the idea of > simulating various distortions that occur in broadcast... is there an > ATSC 8VSB modulator? > > > John Clark. > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] code optimization readings
hi all, can anyone suggest some good readings for code optimization in GNURadio... (or even not GNURadio-specific ones?) thanks vincenzo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Soft-DVB working flawlessly @ correct bitrate.. (=11.612Mbps)
2007/11/22, Teun van Berkel <[EMAIL PROTECTED]>: > > Hi Vicenzo, > > first of all, great work, the video really looks cool. Just a couple > of questions. thanks You have build a DVB-t transmitter, right? yup > The video you are > transmitting (The soccer video), is that stored on your local > harddrive? it comes from an MPEG2 transport stream which was captured when we (Italy) won the 2006 WorldCup :D the ts is just the input to my modulator which is entirely implemented in software,baseband samples for the consequent OFDM signal are calculated (not yet in real time, but it is achievable) and then sent out for the usrp to make them a real world signal, and place it where it is due in the UHF spectrum. > Or did you receive a local DVB-t signal and converted it to > a different frequency before transmitting it again? it is a bit > unclear to me how where you get your video source from. > > Are you using the DVB-t setting with roughly 8000 subcarriers? Is it no it is a 2K for now still possible to do an IFFT with this many subccariers real-time? My > guess would be that this is the limited factor for real-time > transmission. > > Really hope you could answer these questions, > > Thanks, you're welcome Teun van Berkel vincenzo On Nov 21, 2007 2:22 AM, Vincenzo Pellegrini <[EMAIL PROTECTED]> wrote: > > Hi all > > thanks again for precious help, > > > > I'll soon start working on code cleaning and optimization for real time > > performance of my Gnuradio DVB Tx. > > > > here is a video showing latest improvements in transmitted signal.. > > > > http://wwvince.interfree.it/Soft-DVB > > > > h264 video as usual > > > > Best Regards > > > > vincenzo > > > > ps > > > > Matt ..is the VHF/UHF frontend release date confirmed somewhere around > > January? > > > > Thanks > > > > > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > -- Vincenzo Pellegrini ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Soft-DVB working flawlessly @ correct bitrate.. (=11.612Mbps)
Hi all thanks again for precious help, I'll soon start working on code cleaning and optimization for real time performance of my Gnuradio DVB Tx. here is a video showing latest improvements in transmitted signal.. http://wwvince.interfree.it/Soft-DVB h264 video as usual Best Regards vincenzo ps Matt ..is the VHF/UHF frontend release date confirmed somewhere around January? Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] hardware speedup factor starting from AMD Sempron 3000+
hi everybody, I have got my ETSI DVB-T transmitter code working on my linux box, which is based upon an AMD sempron 3000+ (single core) processor. Can anybody roughly esteem the speed up factor that I would have by upgrading to a state of the art desktop processor (maybe a dual core Intel Penryn)? Can I expect my code, as it is, to take some advantage of a multicore architecture? the gnuradiO REVISION i'm using is 3.01 thanks vincenzo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNURadio based ETSI DVB-T Transmitter works. Thanks to everybody for precious help!
Hi everybody, I would like to say thanks to Eric, Firas, Matt, Achilleas and to the other guys from the list from which I received an incredibly precious help. My draft ETSI DVB-T transmitter works fine.. (It's gonna be the subject of my final thesis here @ Pisa University) the code is not yet clean, and I'm still far from real-time, but the signal is pretty good.. and carries its 11.612 Mbps flawlessly. The work I still have to do is improving the code, and making it more efficient, then, if this project might be of some relevance to the community, I'll start a proper procedure for contributing it to gnuradio. there are two videos showing how things go so far @ http://wwvince.interfree.it/11.3Mbps http://wwvince.interfree.it/video2 they're h264, VLC is fine with them I still got one problem, the mpeg ts I'm using as the input to my system is a dump from a commercial transmission on the air here in italy, and it is meant for a 24Mbps channel, so RX buffer tipically has underruns as my channel only carries 11.612. Does anybody know of any open source DVB multiplexer (capable of writing also the NIT) that I could use to set up a mux at the right bitrate? best regards -- Vincenzo Pellegrini ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] asymmetric USRP throughput
I'm beginning to see some light over my 8MHz tx problems.. the throughput towards my USRP is significantly reduced compared to the one from it... ./test_usrp_standard_tx xfered 1.34e+08 bytes in 5.46 seconds. 2.457e+07 bytes/sec. cpu time = 0.492 0 underruns ./test_usrp_standard_rx xfered 1.34e+08 bytes in 4.19 seconds. 3.2e+07 bytes/sec. cpu time = 0.384 noverruns = 0 what could be the cause for this? any hint..? ( benchmark_usb.py reports a good throughput up to 32M) thanks vincenzo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 8 MHz Tx Bandwidth... What am I still missing?
Hi, what I've done so far is: --buy a new hardisk (a 7200 rpm sata), used only for the data to be transmitted,, and XFS formatted ---check my PC's USB bus via gnuradio benchmark_usb.py, which says everything is ok up to 32MB/s (output follows) ---use short int interleaved I/Q instead of gr_complex but still a 342958080 bytes long file, meant to last 10.717 seconds if played back at 32 MB/s (8 complex Msps) lasts 13+ seconds while, instead it should be: 342958080 / 32e6 = 10.717 seconds samples are damn slow to come out..this is quite frustrating as my application needs a true 8 MHz bandwidth... scaling down to 4 MHz is instead fine.. as I really get the right 342958080 / 16e6 = 21.435 seconds what else should I check/modify? any hint? the file meant to last 10.717 secs if played back with usrp_interp = 16 is at http://wwvince.interfree.it/of.dump please, if anybody manages to send it out in not more than 11 seconds, le me know.. it would be really good news... thanks vincenzo BENCHMARK_USB OUTPUT: [EMAIL PROTECTED] gr-mystuff]# ./monitor.sh Testing 2MB/sec... usb_throughput = 2M ntotal= 100 nright= 986311 runlength = 947654 delta = 52346 OK Testing 4MB/sec... usb_throughput = 4M ntotal= 200 nright= 1997961 runlength = 1997961 delta = 2039 OK Testing 8MB/sec... usb_throughput = 8M ntotal= 400 nright= 3997979 runlength = 3997979 delta = 2021 OK Testing 16MB/sec... usb_throughput = 16M ntotal= 800 nright= 7997477 runlength = 7997477 delta = 2523 OK Testing 32MB/sec... usb_throughput = 32M ntotal= 1600 nright= 15995879 runlength = 15991525 delta = 8475 OK Max USB/USRP throughput = 32MB/sec -- Vincenzo Pellegrini ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 8MHz Tx Bandwidth.. Nightmare and Fear
I'm recording and replaying interleaved shorts @ 8Msps.. how is the benchmarking software called? I also have noticed a diffference between my main, old gnuradio installation and a fresh one just done from trunk on another disk... the fisrt is all right with transmissions up to 4 MHz the second stops at 2MHz, (using the same scripts of mine on both installations): when, on the fresh installation, I ask for 4MHz I can hear only noise being sent out (I think this is a different problem than the slow flow).. I'm a bit confused... thanks vincenzo 2007/9/7, Firas abbas <[EMAIL PROTECTED]>: > > Hi Vincenzo, > > Are you recording the 8Msps complex or short ?. In recording, I always > prefer the interleaved complex short, because the real coming samples from > the USRP across the USB is 16 bit short. The conversion to float (32 bit) > complex is being done by software in the PC and thus adds no new information > and does not enhance the data. It only complicate file storage process. If > converting to short does not solve your problem, try to record and play > smaller bandwidth like 6.4MHz (decimation 10) or less. Also test your > PC USB 2 speed by using the benchmark software found the gnuradio truck. > > Best Regards, > > Firas > > *Vincenzo Pellegrini <[EMAIL PROTECTED]>* wrote: > > hi Firas, thanks for help! > > i'm doing pretty much everything you suggested, and in fact, really!!, I > do think that my HD is doing a very good work. > > nevertheless I keep having the same problem, > this is what I also posted to the list: > > > > > > > > > > I finally have a 7200rpm disk that does keep up very well with 32MBps > and, I guess, even much more.. > > is then this assumption correct? > > 8Msps with gr_complex data type ==> 8e6*8bytes per sample = 64 MB/s > > 8Msps with interleaved shorts ==> 8e6*2bytes per int * 2channels = 32 > MB/s > > I'm sure now that my drive can keep up with recording and replaying the > 32 MB/s > and I guess that even 64 with my new, xfs formatted clean disk is fine > > my problem is that in both cases ( both using complex and interleaved > shorts) > > If I work with a 4 MHz bandwidth everything looks allright. > I can record and replay a 4 MHz fm band and perfectly listen to the > station at the center of it when sending it back to the receiver > > but > > when I try to go 8 MHz I can hear a noisy, extremely weak replica of my > signal, which is SLOW... like an old cassette player with flat batteries > > and this is consistent with the fact that a file meant to last 10.717 > secs @ 32MB/s, when played with usrp_interp= 16 (8MHz Bandwidth) > lasts MORE than 13 secs, while if played with usrp_interp=32 (4MHz), > it lasts exactly the double of the correct value ie: 10.717*2=21.434 > > has this ever happened to anybody.. am I making huge mistakes that I > havent discovered yet? > > thanks > > vincenzo > > > On Wed, 2007-09-05 at 13:15 -0700, Firas abbas wrote: > > Hi Vincenzo, > > > > Sorry for this delay, but I didn't saw your email in the mailing list > > which I usually check. To solve your problem do : > > > > 1) Buy SATA II harddisk drive > > 2) Put Linux in ext3 partition > > 3) Create a small Ext2 partition for your recordings (about > > 4Gbyte) > > 4) Whenever you want to record or replay data use this ext2 partition > > 5) When you want to record a new file, move the old file from the Ext2 > > partition to another partition Ext3. Always keep in mind that the ext2 > > partition should be totally empty before any new recording. Also don't > > forget to empty the Trash after each file deletion from the Ext2 > > partition. > > > > I hope I made it clear. For more information send me an email. > > > > Best regards, > > > > Firas > > > > > > Vincenzo Pellegrini wrote: > > On Mon, 2007-09-03 at 20:04 -0700, Eng. Firas wrote: > > > Hi Vincenzo, > > > > > > > > > 1) What is your recording system (PC specifications)?. > > > 2) How fast your hard drive can read/write data? because > > working with 8MHz > > > means that your hard drive must be able to sustain writing > > 32MByte/sec? > > > 3) Do you use ext2 or ext3 ? Ext2 is very efficient in > > writing. > > > 4) Are you recording complex or interleaved Short 8 MHz > > samples? > > > > > > Firas > > > > first of all thanks for listening Firas, > > I'm using a sempron 3000+, 512MiB of Ram, and the HD is a IDE > > with ext3, > > and yes, 32MB/s is at is nominal limit... I'm using
Re: [Discuss-gnuradio] 8MHz Tx Bandwidth.. Nightmare and Fear
really I was expecting them but I cannot see them, they should be in the terminal right? like uO when receiving and uU when transming right? I cannot see these ones thanks On Wed, 2007-09-05 at 16:35 -0700, Matt Ettus wrote: > Vincenzo Pellegrini wrote: > > I've just checked, at 4 MHz I can not only tune the central station of > > my fm band, really I can perfectly tune all them, all the stations in > > the snaphotted band, even at he extremes, the CIC roll off reall gives > > me no problem at this stage.. > > > > with 8 MHz all this good stuff is simply ..gone > > > > enormous amount of noise and what I can hear is clearly being sent out > > slower than it's due.. > > > > > Do you get overruns? That means your machine can't keep up. > > Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 8MHz Tx Bandwidth.. Nightmare and Fear
I've just checked, at 4 MHz I can not only tune the central station of my fm band, really I can perfectly tune all them, all the stations in the snaphotted band, even at he extremes, the CIC roll off reall gives me no problem at this stage.. with 8 MHz all this good stuff is simply ..gone enormous amount of noise and what I can hear is clearly being sent out slower than it's due.. any hint? thanks vincenzo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] the best file system for reading fast
first of all thanks to all the guys who provided very useful tips for the the HD+File system setup. I finally have a 7200rpm disk that does keep up very well with 32MBps and, I guess, even much more.. is then this assumption correct? 8Msps with gr_complex data type ==> 8e6*8bytes per sample = 64 MB/s 8Msps with interleaved shorts ==> 8e6*2bytes per int * 2channels = 32 MB/s I'm sure now that my drive can keep up with recording and replaying the 32 MB/s and I guess that even 64 with my new, xfs formatted clean disk is fine my problem is that in both cases ( both using complex and interleaved shorts) If I work with a 4 MHz bandwidth everything looks allright. I can record and replay a 4 MHz fm band and perfectly listen to the station at the center of it when sending it back to the receiver but when I try to go 8 MHz I can hear a noisy, extremely weak replica of my signal, which is SLOW... like an old cassette player with flat batteries and this is consistent with the fact that a file meant to last 10.717 secs @ 32MB/s, when played with usrp_interp= 16 (8MHz Bandwidth) lasts MORE than 13 secs, while if played with usrp_interp=32 (4MHz), it lasts exactly the double of the correct value ie: 10.717*2=21.434 has this ever happened to anybody.. am I making huge mistakes that I havent discovered yet? thanks vincenzo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] the best file system for reading fast
Hi all, today I bought a 7200 rpm SATA HD (a seagate barracuda, as Eric suggested some months ago) in order to be able to sustain a complex 8Msps flow (32MB/s) towards the usrp. Once I formatted it with the XFS filesytem, following Rayan's tip, it looked like I was getting the appropriate throughput... is anybody using any other high performance filesystem to do this kind of things? ..just to know if other options exist... thanks vincenzo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 8MHz Tx Bandwidth.. Nightmare and Fear
Matt, Tonight I have been recording slices of commercial FM spectrum, all centered right where a good station transmits, the first slice was 300Khz wide, the second was 2MHz the third was 4MHz then I sent all these signals to my Hifi FM receiver via the basicTX... all went fine and I could hear a good stereo sound from my recordings.. then I tried my nightmare: the 8MHz slice of spectrum the output was extremely weak but you could easily tell from what you could hear that the samples were not being sent out at 8Msps: the very poor audio was also "slow" as it happens when you set the interpolation rate too high, compared to the sample rate your samples were taken at... well, this is not just some attenuation next to the shoulder of my ofdm signal.. this is the whole signal .. gone.. So, I'm really not asking you, Matt, to solve a problem which is my duty to solve...and don't even want to bother the whole list with this stuff... ...but please say it loud, say it clear: "vincenzo, you've made very big mistakes, because the USRP really can transmit an 8MHz wide signal without distorting it significantly, I've tested it"... ..so even if this means that I still got much to learn, and much to work to find out where I'm doing wrong... ...well, it would be much better than being forced to give up what I'm working upon.. please... thanks vincenzo PS. I'm using default FPGA configuration... ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] can our USRP do this? --Help really needed from fellows gnuradioers :)
Hi everybody, I guess I'm doing something wrong with how I use my USRP but I really need someone to confirm that a signal like the one in the attached picture can be transmitted with USRP+BasicTX (or even another board), before I dive into finding the mistake. So Has someone ever verified he's able to transmit an 8 Mhz Wide (7 without the virtual carriers) complex signal like the one shown? Or could anybody be so stupendously kind to try to send this gr_complex data dump (usrp_interp = 16) http://wwvince.interfree.it/of.dump towards a good spectrum analizer ( I don't have one.. :( ) and send me back a picture of the result on the screen? this would be a huge help to ma thesis work... :D thanks thanks thanks vincenzo PS. Matt, can you confirm that what I'm asking is within the USRP's reach? the center frequency I'm using is 212.5MHz with Basic TX, but I keep getting unreasonable outputs... PS2. I know I'm asking much.. but if someone were willing to lend me a hand <>___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Basic Tx Output power
Hi, Matt I think I've figured out how to use the Basic Tx for my purposes, thanks to a functional block schematic contained in the wiki. now I know where to get my Icos(...)-Qsin(...) signal.. I still need to know however what power it delivers to a 50 (or 75) ohm load. What I need to figure out is whether an 8 MHz wide signal, centered at 226.5MHz should be strong enough to be detectable by a commercial dvb-t receiver if I connect directly the Basictx output to its rf input. thanks vincenzo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to get Baseband I/Q from USRP
ok Matt, this is good news. and I got also another question, what is the default output from Basic Tx's TX_A, provided that the board is connected to the TXA Slot? On Thu, 2007-08-30 at 09:59 -0700, Matt Ettus wrote: > Vincenzo Pellegrini wrote: > > Hi all, > > > > which is the best way to get baseband analogue I/Q signals out of the > > USRP? > > > > Use the LFTX board ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to get Baseband I/Q from USRP
Hi all, which is the best way to get baseband analogue I/Q signals out of the USRP? thanks vincenzo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
